Так уж получилось, что я принципиальный противник подробного планирования работ над программным продуктом вообще и использования для этих целей инструментов вроде MS Project в частности. Уж очень часто приходится убеждаться в народной мудрости “Хочешь рассмешить Господа Бога – расскажи ему о своих планах”. Но, поскольку необходимость планирования – это одно из правил игры, то приходится ему следовать. В общем, если партия сказала надо – комсомол ответил на верху решили посмешить Господа, значит будем смешить.
К сожалению, по некоторым вопросам степень моего внутреннего похуи пофигизма еще не достигла достаточной величины для ограждения моего психического здоровья от негативных внешних воздействий. Поэтому сеансы работы с Project-ом остаются серьезным нервными встрясками, заставляющими задуматься о том, на кой лично мне все это надо. С последствиями в виде приступов графоманства :(
Составление плана программного проекта, как и попытки предсказания сроков конкретных работ, имхо, чистой воды гадания. В крайнем случае это попытка зафиксировать в каком-то виде свои оптимистические ожидания. Поскольку делается это в самом начале проекта, когда видимое количество предстоящих работ является лишь верхушкой айсберга.
Еще хуже, когда сроки проекта согласовываются на уровне самого высокого начальства из неведомых разработчику политических, экономических и еще хрен знает каких соображений. Проект изначально оказывается безнадежным, но ситуацию усугубляет еще и необходимость его “прозрачного” ведения. Чтобы максимум руководящих уровней (включая и заказчика) могли видеть его прогресс – вот такая-то задача уже исполнена на 90%, а вот эта всего на 10%, вот здесь работы завершились на 2 дня раньше, а здесь намечается запаздывание на неделю…
При этом, опять же из-за “прозрачности” план не может быть ни излишне детализированным, ни слишком гибким.
Например, задаче “Выпуск версии 2.2.1 протокола MbMsg с поддержкой поля ConfidentialMsg в сообщении SEND” с планируемым сроком реализации 30 минут не место в плане 4-х месячного проекта. Поскольку таких задач будет если пару сотен, то уж несколько десятков точно. А копаться в куче мелких деталей никому не хочется, да и времени это отнимает долго. Хотя, как это не парадоксально, именно такая мелкая задачка может стать настоящим show stopper-ом. И потребовать не 30 минут, а нескольких дней работы сразу нескольких разработчиков.
Еще пример. Допустим, в процессе реализации какой-то фичи возникло подозрение, что в мы не сможем вычитывать данные из БД с нужной скоростью. Поэтому нужно отвлечь какого-то разработчика на написание специализированного теста и проведение эксперимента. Но этой работы в плане не было. Если такие задачки в план включать и соответствующим образом корректировать остальные работы, то это уже прямой путь к микроменеджменту, в результате которого из-за деревьев не будет видно леса.
С другой стороны, начальство так же можно понять – они хотят иметь объективное впечатление о ходе проекта. А как они еще могут его получить? Не вызывать же к себе тим-лидов и не опрашивать каждого из них о том что, как и какие перспективы. Совсем другое дело открыть Project и увидеть какую-то циферку – 20% или 50%, или 97%. Совсем другое дело! Это же не “э-э-э, ну я надеюсь, что к 20-му… э-э-э, нет, к 22-му, у нас будут проходить большинство тестов…” Тут смотришь и видишь – 80% готовности, предположительное запаздывание 2.5 дня – все четко и понятно. Объективно.
Тут уж не могу отказать себе в удовольствии и не постебаться на тему процентов исполнения работ.
Во-первых, лично я признаю всего два показателя – 0% и 100%. Т.е. кусок работы либо сделан, либо нет. Все остальное от лукавого. Один разработчик может написать готовый модуль и объявить о 40% готовности потому, что он еще не проводил серьезных тестов и не закончил его документирование. А второй в такой же ситуации проставит 100%, поскольку он искренне считает, что его работа заключалась именно в написании кода, а тестирование и последующий баг-фиксинг – это уже совсем-совсем другая история.
Во-вторых, есть совершенно замечательный и на 100500% верный афоризм: первые 90% времени уходят на написание 90% кода, на оставшиеся 10% кода уходит еще 90% времени. Т.е., если по графику работ все было зашибись до 90% готовности проекта, то это вовсе не значит, что тоже самое будет и с оставшимися 10%. Как раз на этих 10% с проектом может случиться внезапный, полный, глубокий и окончательный приплыздец.
Поэтому я, как разработчик, который регулярно вляпывается в безнадежные проекты, считаю, что планы и Project-ы – это рюшечки и финтифлюшечки – глаз радуют и настроение создают, но нифига полезного не делают. В безнадежных проектах по крайней мере. (Мнение же менеджмента на данный счет идет в /dev/null – это мой блог и сейчас я говорю как разработчик)
Тем не менее, что-то нужно для того, чтобы следить за развитием проекта и его перспективами. Поскольку даже когда работаешь один над большим куском функциональности, то всего в голове не удержишь – нужно как-то учитывать оставшиеся задачи, ранжировать их по срочности, приоритетности и трудоемкости. А когда в проекте работает несколько людей без такого учета вообще далеко не уедешь. Т.е. что-то нужно, но что именно?
По-идее, как раз для этих целей и должен использоваться Project. Да только для разработки софта он не сильно подходит, имхо. Поскольку софт есть софт – слишком в нем все динамично и изменчиво – начиная от внезапных вбросов от заказчика и заканчивая обнаруженными где-то на этапе финального тестирования просчета в архитектуре проекта. Может быть Project хорош для проектов с более строгими и предсказуемыми этапами (вроде ремонта квартиры – там физически не получится наклеить обои на стены до их выравнивания и шпатлевки). Или же на уровне “крупноблочных” программных проектов – когда в Project оперируют целыми программными компонентами или даже комплексами компонентов, а не тасками вроде “Транслитерация исходящих сообщений”.
На мой взгляд, проектирование и разработка кода в ходе программного проекта – это как задача о рюкзаке. Известен конечный срок и команда разработчиков (что в совокупности и образует рюкзак). Нужно определить список вещей (тасков), которые в него должны уместиться.
Например, в самом начале это может быть что-то вроде (здесь и далее подвергшиеся цензуре выжимки из текущего проекта):
- Разработка TP.
- Адаптация cp_service к особенностям проекта XYZ.
- Адаптация AAG с особенностям проекта XYZ.
- Разработка TLV_Gate для связи нескольких cp_service с одним TP.
Т.е. понятно, что в принципе нужно делать. Но еще не понятно, как именно. Хотя это не страшно. Главное в драку ввязаться, а там разберемся ;)
Когда работы начнутся, то ранее обозначенные куски начнут дробиться (заменяться) на блоки из все более и более четких, но мелких кусочков. В результате, на каком-то шаге работы первоначальный список из 4-х обобщенных пунктов преобразуется к чему-то вроде:
Библиотека ig_cp_service_iface-2.2.0 с поддержкой необязательного s_id (для исходящих и входящих сообщений).Поддержка s_id для исходящих сообщений в cp_service.Поддержка s_id для входящих сообщений в cp_service.Первая версия TP, которая использует SOP/MBAPI для взаимодействия с cp_service. Без дозирования трафика и мониторинга.- Имитатор cp_service+AAG на основе SOP/MBAPI, который мог бы использоваться для нагрузочного тестирования TP.
- Проверка первой версии TP без дозирования трафика на имитаторе cp_service+AAG.
- Вторая версия TP, доработанная с учетом испытаний на имитаторе cp_service+AAG.
- Доработка cp_service таким образом, чтобы он отсылал КП только финальные SR-ы, но не отсылал промежуточных.
- Доработка cp_service таким образом, чтобы для некоторых приоритетов (возможно некоторых, а не всех КП) не проводилось динамического понижения приоритетов.
- Библиотека ig_cp_service_iface-2.2.1 с поддержкой поля ConfidentialMsg.
- Реализация в cp_service поддержки ConfidentialMsg.
- Реализация в AAG поддержки ConfidentialMsg.
- Библиотека TLV-представления протокола ig_cp_service_iface-2.2.
- Прототип TLV_Gate который стоит перед cp_service+AAG.
- Добавление в TP поддержки TLV-протокола.
- …
Зачеркнутые пункты обозначают полностью завершенные работы. Остальные либо находятся в работе, либо ждут своей очереди.
По мне, такой список “незаконченных дел” намного нагляднее и объективнее диаграмм из Project-а. Чем меньше в нем незачеркнутых пунктов, тем ближе проект к завершению. Пункты не завязаны кучей зависимостей друг на друга, поэтому их проще изменять, удалять или добавлять новые.
Более того, таких списков можно, да и нужно, вести несколько. Один самого верхнего уровне (вроде приведенного выше). Он дает общее представление о всем проекте. Остальные пониже уровнем, но подробнее. Они могут рассказывать о состоянии конкретной подзадачи (например, описывать список недоделок в имитаторе cp_service+AAG) и могут быть видны только одному конкретному разработчику и, может быть, тим-лиду.
Аналогия с задачей о рюкзаке здесь возникает потому, что по моему опыту, такие списки “незаконченных дел” никогда не оказываются полностью пустыми. Всегда в них остаются какие-то пункты, на которые не хватает ресурсов. Постоянно приходится этот список “ператрахивать”, повышая приоритет для тех пунктов, без которых совершенно нельзя обойтись и понижая приоритет (а то и вычеркивая) пункты, без которых можно обойтись или которыми приходится жертвовать из-за их трудоемкости или неочевидности. Практически как в академической задаче – выбор предметов исходя из их стоимости+объема+веса.
Подобными списками (оформленными на бумаге или в каком-то электронном документе) я пользуюсь давно и регулярно. В принципе, на небольших проектах они работают успешно (в том числе и на безнадежных проектах). Но, к сожалению, поколебать страсть менеджмента к диаграммам Гантта и другим плюшкам Project-а они не смогут. Се ля ви :(
11 комментариев:
вот тут есть мысль на тему "как можно попытаться предсказывать ход работ в ближайшем будущем" и "как вовремя понять, что фичи придётся резать". Полного предварительного планирование крупных проектов, конечно, не выйдет - но небольшое подглядывание в ближайшее будущее тоже неплохо.
и почему собственно "не будешь же"??? именно так и надо делать
причем делать не в мышетыкательном говнопроджекте для умственно отсталых м... ну ладно, не будем говорить кого, а по-прежнему в текстовых файлах; у тебя же есть руби с его реглярками -- им можно объединить мелкие задачи во что-то более крупное, им же можно сделать что-то типа отчета, который потом визуализируется чем-то вроде graphviz (хотя возможно и другой спец. тулзой)
да, главное записать док на тему формата этих текстов и используемых соглашений
профит от текста в том, что нормальные редакторы позволяют очень быстро его набирать при условии, что слова эти уже встечались (не знаю как под виндой, а у нас под линуксом это например kwrite) -- что дает почти весь профит от выпадающих списков и вообще АппликухПоверхБД -- кроме верификации конечно; она видимо и не нужна особо, а если нужна -- то опять в рубяшном скрипте
текст опять же можно держать под системой контроля версий ( = его добавление и редактирование подчиненными, мержи и т.п.) и в перспективе разрешить роботу менять его
правда по-началу я бы не советовал тратить на разработку этого слишком много времени
@iLych:
За ссылочку спасибо, не читал этого материала раньше. Нужно с ним ознакомиться.
@имя:
Не, такая самодеятельность не прокатит. Поскольку Project -- это очень мощная система, которая позволяет получать различные оценки: определять стоящие на критическом пути задачи, оценивать загруженность сотрудников, определять моменты освобождения людей (с возможностью их переключения на другие задачи), подсчитывать стоимость и еще кучу всего, о чем я пока даже не знаю.
Так что, не смотря на мою нелюбовь к Project-у, это весьма мощный и нужный для менеджмента инструмент. При этом огромное количество менеджеров (включая топ-менеджеров) умеют и привыкли им пользоваться. Подсунуть им наколенную разработку на основе txt-файлов -- утопия.
@имя:
Вспомнилось. Когда-то на Palm-е я пробовал использовать програмку (вроде бы она называлась ThoughtManager). Там можно было создавать древовидные планы и выставлять проценты выполнения каждого действия. При этом сама программулина вычисляла процент выполнения родительской задачи на основании процентов выполнения ее подзадач.
В принципе -- это как раз похоже на то, что нужно для программного проекта. Хотя жесткая древовидность, помнится, временами мешала.
Женя, ты ещё один момент забыл:
менеджеры вообще лишний паразитный элемент в софтверной компании. Только лишний гемор от них, отвлечение от работы, паника, несбыточные обещания, требования отчётов, кривой фукнциональности и т.п. :-))))
Остальное в /dev/null :-)
@Lamer:
Слава, так если развивать эту тему, то и продажники менеджеров не должны любить (менеджеры не продают ничего и не производят ничего) и директора (менеджеры никак не могут построить программистов и обеспечить выпуск качественного ПО в строк). Не завидная у вас участь ;)))
Так и есть :-)
На мой взгляд, намного важнее на проекте не планы, а понимание текущего состояния проекта. Достигается это понимание довольно просто: отслеживанием объема работы (scope) и ведением burndown chart'а. Этот самый burndown визуализирует продвижение проекта и даже позволяет приблизительно предсказать, когда мы закончим работу, учитывая то, что нам осталось.
Кроме этого, такая визуализация легко понятна клиентам (руководству) и они сразу же видят, что происходит, когда они набрасывают новые фичи и change request'ы. Воспитательный эффект.
А с планами тоже можно мириться, если не пытаться предугадать события на много месяцев вперед, а делать небольшие итерации длиною в несколько недель.
Хотя, конечно, если необходимо, то можно делать и какое-то высокоуровневое планирование, например, если на проекте есть точки синхронизации с другими командами, событиями или какие-либо другие важные даты.
@Александр Кондуфоров:
Высокоуровневое планирование, конечно же, необходимо.
Вообще, похоже, создал впечатление противника всяких планов. Что не верно ;)
Поэтому я постараюсь выбрать время, чтобы разъяснить это недоразумение.
Отправить комментарий