Работа с заказчиком
«Предоплата ускоряет выполнение всех Ваших прихотей!» — это текст на плакате при входе к тебе в офис.
- Автор(ы): Чобиток Василий, 12-14 марта 2009
- Здесь собраны и постепенно будут пополняться советы как следует и как не следует работать с заказчиком программного обеспечения
Недавно один знакомый руководитель проекта солидной софтверной компании высказал мысль, что по его опыту в неудавшихся проектах в 50 % случаев виноват сам заказчик.
В его возрасте я тоже так думал. Сейчас считаю иначе. Если разработка не завершена в установленный срок, программа не имеет приемлемый уровень функционала или превышен бюджет разработки, практически всегда виноват разработчик. Спокойный анализ тех немногих неудачных проектов, которые у меня были, говорит о том, что во всех случаях кроме одного (он достоин отдельного рассказа) вина в неудаче была именно моя — разработчика. И в других проектах, которые я наблюдал со стороны, то же самое.
Главная проблема в том, что разработчики не умеют работать с заказчиком и не понимают какую роль следует отводить ему в проекте.
В 2005 году я работал в компании «Мнемософт». Для улучшения работы IT-департамента (в Мнемософте этот департамент отвечал за разработку сайтов) провел несколько занятий с программистами по процессу разработки ПО. В результате директор попросил провести обзорную лекцию по этой теме в бизнес-школе, в которой он сам читал лекции. Просьба была озвучена за час до выезда, за это время я успел освежить в памяти лекции и накидать кой-какие слайды.
На занятии получился небольшой конфуз. Директор забыл предупредить о том, какая аудитория будет меня слушать, а я и не подумал спросить — занятия были рассчитаны на разработчиков и иное трудно было предположить. Слушатели, люди серьёзные, были внимательны но как-то воспринимали лекцию без особого энтузиазма. Ближе к концу выступления один товарищ заметил, что мол это всё интересно, но мы тут сидящие не разрабатываем ПО, мы его потребляем и нам интересно не то как строить процесс разработки, а то, какой линии поведения придерживаться при общении с разработчиками, которые всегда опаздывают со сроками, ошибаются с объемами и бюджетом, выдают продукт низкого качества.
Выкрутиться получилось достаточно просто. Мол в том и проблема, что вы работая с программистами, не знаете по каким принципам они должны строить свой процесс, а знание процесса разработки облегчит вам жизнь. После чего постепенно перешел к советам о том как правильно выбрать разработчика (если фирма большая, а с вами с самого начала контачит программист — признак плохой), как правильно с ним общаться (не пытайтесь переходить на его язык, говорите на своём профессиональном; рассказывайте о бизнес-процессах, которые надо автоматизировать, но не рассказывайте о том, какой вы себе представляете будущую программу) и т. д.
Так сложилось, что сейчас я сам в роли заказчика. Смотрю на всё это и думаю, будучи разработчиком каким же иногда я был мудаком…
А теперь некоторые рекомендации, которых следует придерживаться при работе с заказчиком.
Содержание
Говори заказчику правду
- 29.09.2011
Заказчик, пользователи в большинстве своём прекрасно всё понимают. Если у проекта есть проблемы, которые в конце-концов отразятся на заказчике, то следует честно и вовремя об этом сказать. Есть мнение, что «Правду говорить легко и приятно». Понятное дело, я не за патологическую правдивость вроде «Девушка, а у вас ноги кривые!» — это, может быть, и правда, но за неё бьют по морде, и правильно.
Сколько раз сталкивался с ситуациями, когда при работе с заказчиком специалист вместо того, чтобы говорить правду о проекте, пытался «заниматься маркетингом», для «пользы дела» скрывал реальное положение вещей, пытался всё представить в оранжевом свете. На этого специалиста заказчики смотрели с недоверием и не воспринимали всерьёз, потому что реальное положение вещей они и так прекрасно представляли.
Еще в 1993 году на лекции по «Военной педагогике и психологии» преподаватель рассказал такую байку.
- Шел 1917 год, на фронте с немцами полный развал — целые полки и дивизии бросают фронт и эшелонами едут по домам. Фронт перед немцами оголился, Питер защищать некому. И все политические силы, не смотря на непримиримые разногласия, понимают, что войска любой ценой надо возвращать на фронт. Другое дело, немаловажно под чьими политическими знаменами это произойдет...
- На станции стоят эшелоны покинувшей фронт дивизии.
- Приезжает к ним парламентер от монархистов.
- — Братцы! Война до победного конца!
- — А что нам за это обещаешь?
- — Победим, восстановим монархию, каждому поле земли, лошадь, по три коровы...
- — О! Ух ты, знатно поёшь. А как насчет баб?
- — Каждому по бабе будет.
- — Знаешь, мил человек, вали нах отседова!
- Следующий от кадетов:
- — Десять тыщ рублей золотом каждому!
- — А обмундирование?
- — Много нового обмундирования английского сукна, только со складов, всем хватит!
- — И ты, мил человек, вали нах отседова!
- Примерно в том же духе шел разговор и с другими парламентёрами.
- Приезжает комиссар от большевиков.
- — Ты-то что обещаешь? Как насчет денег, земли, баб, обмундирования?
- — А пообещать я могу следующее. Будет холодно, голодно, грязь, в окопах вши и крысы. Пули и смерть. Денег у нас нет, нового обмундирования тоже, оружие то, что при вас, бабы такие же люди и мы их не раздаём. Ещё могу сказать — пустим германца в Питер не будет житья на нашей земле...
- Эшелоны поехали в обратную сторону, на фронт.
Большевик ничего хорошего не обещал, только плохое, а пошли за ним. Почему? Очень просто, он сказал правду. Людям настолько много обещали и так много обманывали, что они не верили никаким уговорам, а пошли за теми, кто ничего хорошего не предложил, но сказал правду, которая и так была известна этим людям.
Мне кажется, что подобные поучительные истории современным специалистам с маркетинговым мышлением не рассказывают.
Пример 1. Из моей практики
Несколько лет назад шло внедрение программы «Атлант» в общие суды Украины. Программа на тот момент была в состоянии альфа-теста, требовала от компьютеров пользователей немалые мощности, к инсталляционному пакету программы на несколько десятков гигабайт дополнительно требовался MS .NET Framework, а на многих компьютерах приходилось ещё переустанавливать операционную систему.
Программа часто тормозила, подвисала, в общем проявляла все прелести программного продукта в состоянии альфа-теста. Причём, из десятков предполагаемых функций программы на тот момент была реализована пока одна. В общем, говорить об удовлетворённости пользователей и хорошем морально-психологическом состоянии сисадминов на местах не приходилось.
Через пару месяцев после эпопеи с установкой программы на компьютеры пользователей по всем судам собираем региональных инженеров на семинар по её использованию.
Первое занятие по функционалу провожу я:
— Насколько я понимаю, «Атлант» уже все ставили и предварительно ознакамливались с ним?
— Ага... Угу...
При этом у народа физиономии кислые, как будто они только что от зубного врача вышли. Я прекрасно понимаю их состояние и без слов знаю мнение о нашей программе. Ну, что же, занятия по военной психологии и педагогике мы не зря посещали:
— Так вот, то что вы увидели сейчас — говно, программа полное фуфло и отстой!
Лица оживились, глаза круглые, народ таким поворотом событий ошарашен — они ожидали выступление представителя «канадской оптовой компании», расхваливающего свой продукт, а тут такое заявление! Причем, в сказанном для них ничего нового — обыкновенная правдивая констатация факта.
После этого я рассказываю, о том, что на самом деле на поверхности пока только одна функция из нескольких десятков, рассказываю о планах того, как мы хотим автоматизировать суды (о реальных планах) и что программа монструозна при мизерном функционале потому, что при разработке архитектуры в неё заранее закладывается фундамент, позволяющий реализовать все те возможности, которые запланированы.
Людям ещё ни разу не рассказывали о планах и не пытались говорить с ними правдиво. Увидев понимание проблемы с моей стороны и то, что им говорят правду, а не маркетинговые лозунги, они включились в работу и, не смотря на мой негативный первоначальный отзыв, настроились на позитив.
Более того, я рекомендовал инженерам рассказывать о программе на местах примерно то же самое — правду.
Знаете что? Не смотря на то, что программа и в самом деле была полным отстоем, и её внедрение до того совершенно не клеилось, после этого семинара внедрение пошло как по маслу (почти) — видя текущие проблемы, люди стали понимать их природу, но и перспективу тоже.
Пример 2. Из моей практики
Сейчас я отвечаю за вики-проект прекрасной игры World of Tanks. Буквально вчера объявили, что с одной из следующих версий игры будет введена поддержка многокластерной технологии, когда один регион (в данном случае русскоязычные игроки) будет обслуживаться несколькими кластерами серверов (сейчас один кластер и он работает на пределе своих возможностей — более 200 тыс. игроков в онлайне одновременно). Причем, многокластерность будет заключаться в том, что при входе в игру игрок сам выбирает, на каком из кластеров играть.
Это решение не понравилось очень многим игрокам, они не хотят разделяться по разным «квартирам». Более того, ряд игроков, разбирающихся в архитектуре подобных систем, высказали мнение, что по-хорошему надо было бы автоматически подключать игрока к менее нагруженному и доступному по пингу кластеру; а при необходимости — автоматически перебрасывать с одного кластера на другой. Ведь пользователь не выбирает сервер в кластере, так почему бы точно так же не заставлять его выбирать кластер?
Казалось бы, причем здесь работа с заказчиком?
Приведу несколько цитат из объявления:
- Цитата 1
- Работа, проводимая нашими специалистами в данном направлении, призвана значительно расширить игровые мощности и сделать игру в World of Tanks максимально комфортабельной.
- Цитата 2
- Использование нескольких кластеров для одного региона обеспечит дополнительные возможности:
- максимальное количество активных игроков в данном регионе значительно возрастет (игроки будут распределены по нескольким кластерам);
- игроки смогут выбирать тот кластер, который обеспечивает максимальный комфорт игры (например, кластер с лучшей связью и минимальной загрузкой);
- игроки в любой момент смогут переключиться на другой кластер ради новых ощущений;
- в случае проведения технических работ или неполадок на одном из кластеров, игроки смогут переключиться на работоспособный кластер.
Что мы видим? Это писал человек с маркетинговым мышлением и здесь не правда, а сплошной маркетинг.
Почему?
Потому что 400 тыс. игроков вместо 200 тыс., для меня, как для игрока, не новая возможность. Когда в бою 30 чел. и не более, мне совершенно пофиг в онлайне 10 тыс. или 400 тыс.
Возможность выбирать кластер... Это не возможность, это лишний функционал на стороне пользователя и лишний ему геморрой.
Переключиться на другой кластер ради «новых ощущений» может только клинический идиот — всё так же случайно подобраны игроки в команды случайных боёв, все те же партнёры в ротных боях. В чём новые ощущения?
Точно так же переключать на другой кластер при технических работах можно было бы автоматически и это тоже не новая возможность, а новый геморрой.
Вполне закономерно, что этот «маркетинг» вызвал бурю эмоций на форуме, игроки просто «срут кирпичами»!
И среди сотен постингов SerB (главный гейм-дизайнер) на очередное предложение сделать работу кластеров автоматической и скрытой от пользователей ответил: «Это было бы идеальным вариантом. Однако по ряду архитектурных и технических причин такое пока невозможно. По крайней мере, в требуемые нам сроки.»
Вот правда, она проста и понятна. И что мешало именно об этом написать в объявлении? — наплыв игроков требует кардинальных и срочных мер, есть хорошие решения, но они нереализуемы в приемлемые сроки, поэтому за основу взято не самое удачное, но реализуемое.
Спрашивается, кто был бы недоволен, если вместо «маркетинга» пользователям была бы сказана правда? Игроки отнеслись бы с пониманием и способности самих разработчиков не подвергались сомнению.
- Разработчик! Пользователь не враг твой, говори ему правду.
Что хочет Бог Заказчик?
- 22.06.2010
Только ради этого диалога в конце фильма:
- Архангел Гавриил: Не может быть! Ты же ослушался Его!
- Архангел Михаил: Ты дал Ему то, что Он просил… Я — то, что Ему было нужно.
стоит посмотреть «Легион» (2010 год).
- Уж сколько раз твердили миру,
что можно угодить заказчику не выполнением указаний,
а токмо удовлетворением его потребностей.
Но грабли не новы, а воз и ныне там… (прошу простить за вольности в пересказе дедушки Крылова)
Не парь заказчику мозги
- 12.03.2009
Заказчик по определению не специалист в области программирования, тем более, в области руководства и аналитики программных проектов. Нет, бывают конечно исключения, но исходить надо из этого — заказчик не знает как правильно разрабатывать программы, но он специалист в своей предметной области (далеко не всегда, к сожалению) и именно этим и должен быть ценен для разработчика и проекта.
Посему, не парь мозги заказчику своими заморочками, связанными с твоим субъективным пониманием того, как правильно писать программы и управлять эти процессом. Да, работать с заказчиком надо постоянно, встречаться как можно чаще но говорить не о будущей программе, а о той подлежащей автоматизации работе, которой он, заказчик, занимается. За первый месяц проекта ты должен стать таким же врачом, каким врач-заказчик стал за пять лет учёбы и десять лет работы; таким же прокурором, каким стал прокурор-заказчик за… и т. д., и т. п.
Кто делает ТЗ?
- 13.03.2009
Извечная проблема связана с тем, кто пишет техническое задание (ТЗ) и разрабатывает требования.
Конечно же, ТЗ разработчику выдаёт заказчик и требования выдвигает он же, что неоспоримо. Однако, это совершенно не означает, что ТЗ заказчик пишет. Если ты разработчик с опытом, то о ТЗ на программу должен знать всё, ведь сколько проектов ты сделал, столько ТЗ (не меньше) по идее и должно было через тебя пройти. Что знает о ТЗ на программу среднестатистический заказчик? Ровным счётом ничего, он их никогда не писал, не видел, что в них должно быть условно догадывается. Поэтому возьми это на себя — разработчик сделает ТЗ намного быстрее, а пока будет делать, то ещё и получит необходимые знания предметной области. Естественно, писать ТЗ надо максимально привлекая заказчика.
То же самое и с требованиями. Правильно оформить требования для заказчика проблема. Следуя совету из предыдущего пункта, не надо парить ему мозги, пусть озвучивает свои пожелания к программе, а ты документируй требования за него.
Оформленные ТЗ и требования (для простых проектов это может быть один документ) обязательно согласовываются и утверждаются заказчиком.
Помни! Согласованное и утвержденное ТЗ устаревает в момент его утверждения!
Сбор и документирование требований
- 14.03.2009
- Подробнее см. «сбор требований»
Строгое следование спецификациям
Тщательно задокументируй всё то, что заказчик хочет и озвучивает. Дай получившееся ему на подпись и при разработке строго следуй этим требованиям. В результате получится полная хрень!
Не для того ты на этом рынке работаешь и не для того мозги тебе дадены, чтобы так бездарно управлять требованиями.
Задавай правильные вопросы
Чтобы продукт получился, он должен решать определенные цели, потребности клиента. Поэтому неуместны вопросы, которые обычно задают аналитики: «Что ты хочешь?», а еще хуже — «Как ты хочешь?»
Уместным является вопрос именно о целях. Однако, если так и попросить «Сообщи цели», то заказчик, скорее всего, впадет в ступор, ему будет сложно вот так сразу взять и определить цели — это слишком высокие материи… Поэтому наилучшим есть вопрос «Зачем тебе это нужно?» — понятно и на такой вопрос легко отвечать, если человек что-то хочет, он сможет объяснить зачем ему это нужно (а это и есть его цель, реальная потребность).
Управление ошибками и запросами на изменение
- 26.05.2009
Ошибки бывают разные. К ним относятся как банальные «глюки» — исключительные ситуации, которые не обрабатываются программой, так и несоответствие реализации требованиям. Запросы на изменение — те же требования к программе, только возникшие после разработки определенного функционала, когда стало понятно, что его следует доработать или изменить. Управление теми и другими практически не отличается. Неконтролируемый процесс выявления ошибок и запросов на изменение может привести к колоссальным потерям времени. И тут важно правильно организовать процесс управления ошибками и запросами на изменение.
В который раз напомню: заказчик по определению не умеет это делать. Заказчик только может ответить на вопрос, что для него важнее, раньше исправить эту ошибку или внести то изменение, то есть определить приоритеты.
И здесь я столкнулся с доведением этого принципа до полного маразма. Разработчики, получив приоритеты, забывают о такой простой вещи, как сложность реализации. Например, все критические замечания (те, без учета которых программа в принципе не работает) ставятся на текущую итерацию, важные на следующую, а полезные ещё дальше. Вроде бы всё просто, однако заказчик не может понять, почему его элементарная просьба «в этой форме, в этом булевом поле галочку по умолчанию включить» ставится в план на реализацию аж через два месяца (!!!). Почему??? Ведь это же две минуты работы!!!
А этот вопрос «почему?» вызывает терпеливое объяснение манагером проекта какой же он сложный этот процесс управления изменениями и как же это важно реализовать по приоритетам, а «галочка» не критична, так как программа и так работает, отвлекать программиста на галочку — потеря времени, а пользователи пусть её два месяца включают. То, что эти два месяца 200 операторов в 95 % из 100 тыс. записей будут лишний раз кликать, чтобы включить «галку» этому, с позволения сказать, манагеру плевать с высокой башни.
Не будь таким же идиотом, как этот манагер. Среди ошибок и запросов на изменение есть элементарные, они вообще не стоят того, чтобы им ставить приоритет. Их просто надо сделать. Сразу. Без обсуждения. Вместе с программистом, за его рабочим местом, пройдись по всему списку и обсуди сложность реализации каждого запроса и те, которые элементарны, программист пусть исправит сразу, мгновенно, без обсуждений, и вычеркнет эти пункты из списка. Таких пунктов, как правило, до половины — потратив два часа работы и сократив список со 100 до 50 позиций вы экономите дни и недели работы, которые были бы потрачены на бесполезное взаимное мозгополоскание якобы процессом управления изменениями. Помни, это не ебля, здесь важен не процесс, а результат! Естественно, вычеркнутые пункты можно сразу же сообщить тестировщику для их немедленной проверки.
И заказчик будет удовлетворён, он не будет биться в истерике головой ап стену, пытаясь понять, почему «этим идиотам» для замены слова «конь» на «кобыла» в заголовке окна нужен месяц, а чтобы просто «включить галочку» надо с серьезным видом обсудить приоритет, потратив больше времени на обсуждение, чем нужно на саму реализацию, и еще выслушать нотацию этого недоделанного менеджера как важно понимать, что без включенной галочки программа и так будет работать, потому она не критична и её можно сделать позже, для чего этот самый манагер лично запланирует галочку на одну из последующих итераций, обязательно после изменения коня на кобылу и до изменения серого шрифта на светло-сером фоне на черный…
Не хочешь утонуть в мелочах? Устраняй мелкие проблемы не отходя от кассы!
И ещё раз напомню: Не парь заказчику мозги! — это не он виноват в том, что ты не умеешь работать.
Не хами!
- 27.05.2009
Конечно, не нужно целовать заказчика в обе ягодицы только потому, что он платит деньги. Однако, его следует уважать и не следует ему хамить.
Если ты предлагаешь идею, направленную на оптимизацию процессов работы заказчика и он её не воспринимает — спорь с заказчиком, до криков, до хрипоты но корректно и без хамства. В споре рождается истина и если ты болеешь за своё дело, хочешь помочь заказчику и поэтому в споре переходишь на повышенный тон, это хорошо, и нормальный заказчик это оценит верно. После такого спора, когда была рождена истина, оба выйдут из кабинета побитые, с синяками но довольные достигнутым результатом.
Есть и противоположные примеры. Недавно получил от манагера одного из проектов письмо:
Вася, получил задачу от твоих людей с вопросом почему поиск на сайте по сочетанию: «Гумовий виріб № 5» выдал так много результатов. После разборок оказалось, что результат поиска правильный, просто автор вопроса не понимает, что такое контекстный поиск.
После выяснения обстоятельств, оказалось: результаты поиска действительно выглядели неадекватными, что вызвало вполне закономерные вопросы. Вместо пояснения сути проблемы высказывать «автор вопроса не понимает» — хуже чем хамство, это мудачество. Следует понимать, что общаться с мудаком намного неприятнее, чем с хамом.
Ссылки
- Manifesto for Agile Software Development (Манифест гибкой методологии разработки)
