суббота, 19 марта 2011 г.

[work.thoughts] Поток сознания о планах проектов и задаче о рюкзаке

Так уж получилось, что я принципиальный противник подробного планирования работ над программным продуктом вообще и использования для этих целей инструментов вроде 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 оперируют целыми программными компонентами или даже комплексами компонентов, а не тасками вроде “Транслитерация исходящих сообщений”.

На мой взгляд, проектирование и разработка кода в ходе программного проекта – это как задача о рюкзаке. Известен конечный срок и команда разработчиков (что в совокупности и образует рюкзак). Нужно определить список вещей (тасков), которые в него должны уместиться.

Например, в самом начале это может быть что-то вроде (здесь и далее подвергшиеся цензуре выжимки из текущего проекта):

  1. Разработка TP.
  2. Адаптация cp_service к особенностям проекта XYZ.
  3. Адаптация AAG с особенностям проекта XYZ.
  4. Разработка TLV_Gate для связи нескольких cp_service с одним TP.

Т.е. понятно, что в принципе нужно делать. Но еще не понятно, как именно. Хотя это не страшно. Главное в драку ввязаться, а там разберемся ;)

Когда работы начнутся, то ранее обозначенные куски начнут дробиться (заменяться) на блоки из все более и более четких, но мелких кусочков. В результате, на каком-то шаге работы первоначальный список из 4-х обобщенных пунктов преобразуется к чему-то вроде:

  1. Библиотека ig_cp_service_iface-2.2.0 с поддержкой необязательного s_id (для исходящих и входящих сообщений).
  2. Поддержка s_id для исходящих сообщений в cp_service.
  3. Поддержка s_id для входящих сообщений в cp_service.
  4. Первая версия TP, которая использует SOP/MBAPI для взаимодействия с cp_service. Без дозирования трафика и мониторинга.
  5. Имитатор cp_service+AAG на основе SOP/MBAPI, который мог бы использоваться для нагрузочного тестирования TP.
  6. Проверка первой версии TP без дозирования трафика на имитаторе cp_service+AAG.
  7. Вторая версия TP, доработанная с учетом испытаний на имитаторе cp_service+AAG.
  8. Доработка cp_service таким образом, чтобы он отсылал КП только финальные SR-ы, но не отсылал промежуточных.
  9. Доработка cp_service таким образом, чтобы для некоторых приоритетов (возможно некоторых, а не всех КП) не проводилось динамического понижения приоритетов.
  10. Библиотека ig_cp_service_iface-2.2.1 с поддержкой поля ConfidentialMsg.
  11. Реализация в cp_service поддержки ConfidentialMsg.
  12. Реализация в AAG поддержки ConfidentialMsg.
  13. Библиотека TLV-представления протокола ig_cp_service_iface-2.2.
  14. Прототип TLV_Gate который стоит перед cp_service+AAG.
  15. Добавление в TP поддержки TLV-протокола.

Зачеркнутые пункты обозначают полностью завершенные работы. Остальные либо находятся в работе, либо ждут своей очереди.

По мне, такой список “незаконченных дел” намного нагляднее и объективнее диаграмм из Project-а. Чем меньше в нем незачеркнутых пунктов, тем ближе проект к завершению. Пункты не завязаны кучей зависимостей друг на друга, поэтому их проще изменять, удалять или добавлять новые.

Более того, таких списков можно, да и нужно, вести несколько. Один самого верхнего уровне (вроде приведенного выше). Он дает общее представление о всем проекте. Остальные пониже уровнем, но подробнее. Они могут рассказывать о состоянии конкретной подзадачи (например, описывать список недоделок в имитаторе cp_service+AAG) и могут быть видны только одному конкретному разработчику и, может быть, тим-лиду.

Аналогия с задачей о рюкзаке здесь возникает потому, что по моему опыту, такие списки “незаконченных дел” никогда не оказываются полностью пустыми. Всегда в них остаются какие-то пункты, на которые не хватает ресурсов. Постоянно приходится этот список “ператрахивать”, повышая приоритет для тех пунктов, без которых совершенно нельзя обойтись и понижая приоритет (а то и вычеркивая) пункты, без которых можно обойтись или которыми приходится жертвовать из-за их трудоемкости или неочевидности. Практически как в академической задаче – выбор предметов исходя из их стоимости+объема+веса.

Подобными списками (оформленными на бумаге или в каком-то электронном документе) я пользуюсь давно и регулярно. В принципе, на небольших проектах они работают успешно (в том числе и на безнадежных проектах). Но, к сожалению, поколебать страсть менеджмента к диаграммам Гантта и другим плюшкам Project-а они не смогут. Се ля ви :(

Отправить комментарий