Участник:ArmorAdmin/Работа с заказчиком

Это незавершенная статья, вы можете помочь проекту исправив и дополнив её

Не парь заказчику мозги

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

Посему, не парь мозги заказчику своими заморочками, связанными с твоим субъективным пониманием того, как правильно писать программы и управлять эти процессом. Да, работать с заказчиком надо постоянно, встречаться как можно чаще но говорить не о будущей программе, а о той работе, которой он, заказчик, занимается. За первый месяц работы ты должен стать таким же врачом, каким врач-заказчик стал за пять лет учёбы и десять лет работы; таким же прокурором, каким стал прокурор-заказчик за… и т. д., и т. п.

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

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

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

Опять же, любая работа начинается с планирования. А планировать, как это ни грустно звучит, в программной индустрии умеют считанные единицы. Более того, не могу с уверенностью сказать умею ли планировать программные проекты я сам :-)

Раз человечество выработало механизм постепенного углубления в проблему «от общего к частному», то стоит ли изменять ему при планировании программных проектов?

В КТЦ, где я имел честь служить пять лет, учили создавать перспективный план части (на пять лет), годовой план части, годовой план отдела, план на тему в целом, квартальный план темы, месячный план и вплоть до недельного плана отдела.

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

Так может быть такое планирование не было точным? Оно было точным и по результатам выполнения темы отклонение в часах на 10 % от первоначального плана уже считалось большим. Да, бывали и переносы на другой период, если заказчик не смог вовремя предоставить исходные материалы, бывали увеличения плановых показателей, если по ходу выяснялось, что заказчику требуется больше, чем изначально планировалось. Но на каждые десять тем таких было не больше одной-двух. То есть методы планирования, которые использовали наши отцы и деды, работают! Планировать надо от общего к частному, но не в иную сторону!

Зачем я так подробно остановился на том, как было в КТЦ? Уже не раз сталкивался с идиотским посылом среди манагеров новой формации, что «пока мы не распишем все задачи (вплоть до каждого моллюска), план на проект выдать не можем».

Это порочный подход, и вот почему. Допустим, что в начале проекта тебе о проекте известно буквально всё (хотя, так не бывает, по определению, никогда) и ты длинный список частных задач выдал программеру. Например, он, оценивая каждую задачу, ошибается в два раза (вместо двух дней у него один, вместо месяца — две недели). Просто потому, что ему впадлу показаться недотёпой, который медленно работает. Кроме того, оценка каждой такой задачи в начале проекта в любом случае не учитывает многие изначально неизвестные факторы, которые проявятся позже. Итого, вместо например года мы получаем полгода…

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

А еще, открою секрет, у заказчика есть свои сроки. Но это не абстракции, как у разработчика. Например, с 1 апреля по закону о резинотехнических изделиях необходимо организовать строгий номерной учёт выданных резинок. Планируй что хочешь и как хочешь, а появиться вечером 31 марта и радостно сообщить, что усё готово, это — провал. То есть за месяц, 1 марта, должно было начаться обучение операторов; ещё за месяц до того программа должна была пройти приёмо-сдаточные испытания; ещё за месяц до того заказчик должен был увидеть стабильную версию программы, кандидат на выпуск; а периодически до того он должен был бы видеть и промежуточные версии, чтобы понимать, как идет проект.

Риски

Не подменяй управление рисками прикрывательством собственной жопы.