Версия 11:15, 21 июля 2009

Работа с заказчиком

Автор(ы): Чобиток Василий, 12-14 марта 2009

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

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

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

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

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

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

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

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

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

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

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

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

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

Идеальное ТЗ существует

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

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

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

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

Помни! Согласованное и утвержденное ТЗ устаревает в момент его утверждения!

Сбор и документирование требований

Подробнее см. «сбор требований»

Строгое следование спецификациям

Тщательно задокументируй всё то, что заказчик хочет и озвучивает. Дай получившееся ему на подпись и при разработке строго следуй этим требованиям. В результате получится полная хрень!

Не для того ты на этом рынке работаешь и не для того мозги тебе дадены, чтобы так бездарно управлять требованиями.

Задавай правильные вопросы

Чтобы продукт получился, он должен решать определенные цели, потребности клиента. Поэтому неуместны вопросы, которые обычно задают аналитики: «Что ты хочешь?», а еще хуже — «Как ты хочешь?»

Уместным является вопрос именно о целях. Однако, если так и попросить «Сообщи цели», то заказчик, скорее всего, впадет в ступор, ему будет сложно вот так сразу взять и определить цели — это слишком высокие материи… Поэтому наилучшим есть вопрос «Зачем тебе это нужно?» — понятно и на такой вопрос легко отвечать, если человек что-то хочет, он сможет объяснить зачем ему это нужно (а это и есть его цель, реальная потребность).

Управление ошибками и запросами на изменение

Ошибки бывают разные. К ним относятся как банальные «глюки» — исключительные ситуации, которые не обрабатываются программой, так и несоответствие реализации требованиям. Запросы на изменение — те же требования к программе, только возникшие после разработки определенного функционала, когда стало понятно, что его следует доработать или изменить. Управление теми и другими практически не отличается. Неконтролируемый процесс выявления ошибок и запросов на изменение может привести к колоссальным потерям времени. И тут важно правильно организовать процесс управления ошибками и запросами на изменение.

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

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

А этот вопрос «почему?» вызывает терпеливое объяснение манагером проекта какой же он сложный этот процесс управления изменениями и как же это важно реализовать по приоритетам, а «галочка» не критична, так как программа и так работает, отвлекать программиста на галочку — потеря времени, а пользователи пусть её два месяца включают. То, что эти два месяца 200 операторов в 95 % из 100 тыс. записей будут лишний раз кликать, чтобы включить «галку» этому, с позволения сказать, манагеру плевать с высокой башни.

Не будь таким же идиотом, как этот манагер. Среди ошибок и запросов на изменение есть элементарные, они вообще не стоят того, чтобы им ставить приоритет. Их просто надо сделать. Сразу. Без обсуждения. Вместе с программистом, за его рабочим местом, пройдись по всему списку и обсуди сложность реализации каждого запроса и те, которые элементарны, программист пусть исправит сразу, мгновенно, без обсуждений, и вычеркнет эти пункты из списка. Таких пунктов, как правило, до половины — потратив два часа работы и сократив список со 100 до 50 позиций вы экономите дни и недели работы, которые были бы потрачены на бесполезное взаимное мозгополоскание якобы процессом управления изменениями. Помни, это не ебля, здесь важен не процесс, а результат! Естественно, вычеркнутые пункты можно сразу же сообщить тестировщику для их немедленной проверки.

И заказчик будет удовлетворён, он не будет биться в истерике головой ап стену, пытаясь понять, почему «этим идиотам» для замены слова «конь» на «кобыла» в заголовке окна нужен месяц, а чтобы просто «включить галочку» надо с серьезным видом обсудить приоритет, потратив больше времени на обсуждение, чем нужно на саму реализацию, и еще выслушать нотацию этого недоделанного менеджера как важно понимать, что без включенной галочки программа и так будет работать, потому она не критична и её можно сделать позже, для чего этот самый манагер лично запланирует галочку на одну из последующих итераций, обязательно после изменения коня на кобылу и до изменения серого шрифта на светло-сером фоне на черный…

Не хочешь утонуть в мелочах? Устраняй мелкие проблемы не отходя от кассы!

И ещё раз напомню: Не парь заказчику мозги! — это не он виноват в том, что ты не умеешь работать.

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

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

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

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

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

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

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

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

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

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

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

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

Риски

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

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

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

Не хами!

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

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

Есть и противоположные примеры. Недавно получил от манагера одного из проектов письмо:

Вася, получил задачу от твоих людей с вопросом почему поиск на сайте по сочетанию: «Гумовий виріб № 5» выдал так много результатов. После разборок оказалось, что результат поиска правильный, просто автор вопроса не понимает, что такое контекстный поиск.

После выяснения обстоятельств, оказалось: результаты поиска действительно выглядели неадекватными, что вызвало вполне закономерные вопросы. Вместо пояснения сути проблемы высказывать «автор вопроса не понимает» — хуже чем хамство, это мудачество. Следует понимать, что общаться с мудаком намного неприятнее, чем с хамом.

Примечания

1. ↑ Тема — то же, что в программной индустрии принято называть проектом.

Ссылки

• Manifesto for Agile Software Development