Мы сделаем этот велосипед за месяц

Правильное управление процессом разработки это не меньшая проблема, чем собственно правильный код. Начинающие руководители часто даже не задумываются об этом, наступая на одни и те же грабли. На примере одной вымышленной истории попробуем разобраться какие проблемы нас ожидают и что можно сделать.

В статье я не открою никакой тайны, и серебряной пули у меня нет. Также я не претендую на глубокое и качественное знание процесса разработки, но опишу один из простейших подходов, который применяю сам. Здесь будут описаны простые и элементарные вещи, известные всякому опытному руководителю проектов. Статья предназначена прежде всего для начинающих РП, тимлидов, и тех, кто совмещает эти должности. Впрочем, она полезна в любой сложной деятельности.

Велосипед

Итак, Вася долго трудился рядовым программистом, ведущим программистом и наконец стал Руководителем. У него есть команда отчаянных головорезов разработчиков в количестве двух единиц. Безусловно талантливых и знающих свое дело специалистов.

Вася получает первый заказ — надо сделать … велосипед.

К сожалению готовые велосипеды либо слишком дороги либо не подходят заказчику по ряду причин. Отлично, думает Вася, уж велосипеды-то мы делать любим и умеем, и радостно берется за разработку. Вася хоть и начинающий, но уже руководитель, и понимает что надо делать велосипед попроще, т.к. помнит про сроки, договоры, бюджеты и все остальное что является фундаментом принятия решений в коммерческой организации. Сделав задумчивое лицо, помолчав минуту, он отвечает заказчику, что на велик уйдет не меньше месяца, т.к. “задача сложная и нестандартная”. Думая про себя, что работы там на две недели, но разумно умножая на два. Вася все-таки был острожным парнем.

Он собирает команду и объявляет задачу: мы делаем велосипед. Заводит парней своим энтузиазмом, выслушивает гениальные идеи от каждого, сам воодушевляется общим настроем и принимает простое и логичное решение: сам Вася, как наиболее опытный, делает раму, Серёга, как лучший знаток передовых технологий, делает колеса, а Петя, как самый молодой, занимается прочим навесным оборудованием. Выпили кофе, порисовали на белой доске маркерами велосипеды в анфас, профиль и в разрезах и сели кодить.
Забегая немного вперед, мы увидим через месяц, что проект на грани провала, команда деморализована, а велосипед хоть уже и ездит, но недалеко и часто падает. Иначе и быть не могло. Что же случилось?

Оставим на мгновение наших славных разработчиков, и посмотрим со стороны, что же у них произошло. В этой истории можно увидеть ряд явных ошибок, однако большинство из них являются следствием главной ошибки, допущенной Василием в самом-самом начале, еще до начала разработки. Василий забыл, что он прежде всего управленец а не программер.

Что же делать?

1. Спроектировать велосипед.
2. Спланировать работы и ресурсы.
3. Назвать заказчику дату.
4. Сделать велосипед.
5. ??????
6. PROFIT!!!!11

Очевидно, в этих пунктах нет никакой тайны. Они понятны и логичны. Однако Вася выполнил в первую очередь п.3, на п.2 забил и получилось то что получилось. На проектировании в данной статье останавливаться не будем, в простейшем случае (велосипед) это обычная декомпозиция задачи. Это Вася вместе с командой выполнил, в отличие от пункта 2.

Планирование работ

Проведем параллель между командой разработки и многопоточным приложением: разработчик как и программный тред, работает лучше, если ему не приходится синхронизироваться с другими тредами. И ему нужно достаточно вводных данных чтобы начать работать. Задача руководителя — грамотно распараллелить работу по имеющимся ресурсам, выстроить максимально эффективную последовательность этапов решения задачи.

Проведем простейшую декомпозицию нашей задачи:

Как видно из истории, у команды постоянно возникали проблемы из-за отсутствия готовой рамы. Следовательно, сначала надо было сделать раму, а потом делать все остальное.

Но чем будут заниматься Серёга и Петя пока Вася будет делать раму? Отдых это конечно хорошо, но не в данном случае. А почему бы не нарисовать сначала раму и договориться о размерах раз и навсегда? Имея нужные размеры Серега и Петя смогут занятся своими задачами. Кстати у нас есть задача по упаковке. Она не сильно завязана на все остальное, и её можно запускать сразу, как будут известны размеры. Итак, у нас все упирается в размеры. Выделим задачу по проектированию размеров рамы и посмотрим что же получится:

Как видно, задачу удалось в самом сложном этапе распараллелить аж на 4 потока. В истории с велосипедом ключевой задачей оказались размеры рамы (аналог интерфейсов взаимодействия). Интерфейсы как правило и являются той важнейшей задачей, которую следует решить в первую очередь, но не всегда. Важно внимательно проанализировать задачу и выявить эту критическую точку. Иногда бывает что это простейшая задачка на 5 минут.

Ресурсы и сроки

Попробуем наложить получившийся план разработки на имеющиеся ресурсы:

У нас получился один из вариантов сетевого графика, широко известного и популярного инструмента планирования.
Теперь понятно кто когда и чем занимается. У Васи нагрузка по разработке самая маленькая, и это не случайно. Как у любого руководителя у него масса административной работы, и на нее нужно оставить достаточно времени.

В данном примере проведена только простейшая декомпозиция. Сознательно упрощая решение, ожидаю что всякий заинтересованный читатель может спланировать разработку велосипеда гораздо лучше. Раскладывая задачу на более мелкие этапы вы сможете во-первых эффективнее задействовать имеющиеся ресурсы, а во-вторых повысите точность оценки сроков. Сложно сказать, сколько вы будете делать велосипед. Но куда проще ответить, сколько времени займет, например, натягивание шины на колесо — десять минут с перекуром. Оценивая срок создания велосипеда в целом вы легко можете ошибиться на порядок. Имея же оценки простых очевидных этапов, вряд ли ошибетесь более чем вдвое. Поэтому на два все-таки надо умножать.
С другой стороны, углубляться в деление на этапы тоже надо разумно, чтобы не просидеть с этим несколько дней. Декомпозировать задачу следует до того момента, пока каждый этап не станет отдельной задачей, выполняемой одной исполнительной единицей(разработчиком) при наличии четко обозначенных входных условий. Делить еще глубже имеет смысл при наличии большого количества исполнителей, чтобы избежать их простоя.

Став тимлидом или руководителем проекта, никогда не забывайте, что ваша основная задача — это управление процессом разработки. Вы можете участвовать непосредственно в написании кода, но по остаточному принципу, работая на подхвате и закрывая дырки там, где не справляется команда. Либо выполняя быстро и качественно наиболее критичные этапы, от которых начинается разделение процесса по исполнителям.
Управление это не магия, интуиция или дар божий. Это кропотливая и методичная работа по систематизации и оптимизации.

PS: статья, включая диаграммы, сделана полностью в Google Docs, ради эксперимента. Удобная штука, как оказалось!