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

Автор(ы): Чобиток Василий

Здесь собраны и постепенно будут пополняться советы как следует и как не следует работать с заказчиком программного обеспечения

Недавно один знакомый руководитель проекта солидной софтверной компании высказал мысль, что по его опыту в неудавшихся проектах в 50 % случаев виноват сам заказчик.

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

Главная проблема в том, что разработчики не умеют работать с заказчиком и не понимают какую роль следует отводить ему в проекте.

В 2005 году я работал в компании «Мнемософт». Для улучшения работы IT-департамента (в Мнемософте этот департамент отвечал за разработку сайтов) провел несколько занятий с программистами по процессу разработки ПО. В результате директор попросил провести обзорную лекцию по этой теме в бизнес-школе, в которой он сам читал лекции. Просьба была озвучена за час до выезда, за это время я успел освежить в памяти лекции и накидать кой-какие слайды.

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

Выкрутиться получилось достаточно просто. Мол в том и проблема, что вы работая с программистами, не знаете по каким принципам они должны строить свой процесс, а знание процесса разработки облегчит вам жизнь. После чего постепенно перешел к советам о том как правильно выбрать разработчика (если фирма большая, а с вами с самого начала контачит программист — признак плохой), как правильно с ним общаться (не пытайтесь переходить на его язык, говорите на своём профессиональном; рассказывайте о бизнес-процессах, которые надо автоматизировать, но не рассказывайте о том, какой вы себе представляете будущую программу) и т. д.

Так сложилось, что сейчас я сам в роли заказчика. Смотрю на всё это и думаю, будучи разработчиком каким же иногда я был мудаком…

А теперь некоторые рекомендации, которых следует придерживаться при работе с заказчиком.

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

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

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

Кто делает ТЗ?

Извечная проблема связана с тем, кто пишет техническое задание (ТЗ) и разрабатывает требования.

Конечно же, ТЗ разработчику выдаёт заказчик и требования выдвигает он же, что неоспоримо. Однако, это совершенно не означает, что ТЗ заказчик пишет. Если ты разработчик с опытом, то о ТЗ на программу должен знать всё, ведь сколько проектов ты сделал, столько ТЗ (не меньше) по идее и должно было через тебя пройти. Что знает о ТЗ на программу среднестатистический заказчик? Ровным счётом ничего, он их никогда не писал, не видел, что в них должно быть условно догадывается. Поэтому возьми это на себя — разработчик сделает ТЗ намного быстрее, а пока будет делать, то ещё и получит необходимые знания предметной области. Естественно, писать ТЗ надо максимально привлекая заказчика.

То же самое и с требованиями. Правильно оформить требования для заказчика проблема. Следуя совету из предыдущего пункта, не надо парить ему мозги, пусть озвучивает свои пожелания к программе, а ты документируй требования за него.

Оформленные ТЗ и требования (для простых проектов это может быть один документ) обязательно согласовываются и утверждаются заказчиком.

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

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

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

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

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

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

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

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

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

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

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

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

Риски

Управление рисками должно быть. Предсказанная проблема — первый шаг к её избежанию.

Если проблема маловероятна и устранима за полдня в случае наступления, вообще не стоит заранее на неё заморачиваться.

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