Участник:ArmorAdmin/Работа с заказчиком — различия между версиями

Материал из Бронетанковой Энциклопедии — armor.kiev.ua/wiki
Перейти к: навигация, поиск
(→‎Не хами!)
м (LostArtilleryMan переименовал страницу Участник:ГОВНЮК/Работа с заказчиком в Участник:ArmorAdmin/Работа с заказчиком поверх перенаправления и б…)
 
(не показано 28 промежуточных версий 4 участников)
Строка 1: Строка 1:
−
= Работа с заказчиком =
+
{{DISPLAYTITLE:Работа с заказчиком}}
 +
<blockquote>''«Предоплата ускоряет выполнение всех Ваших прихотей!» — это текст на плакате при входе к тебе в офис.''</blockquote>
 +
 
 
{{Библиография
 
{{Библиография
 
|Автор = [[Участник:ArmorAdmin|Чобиток Василий]], 12-14 марта 2009
 
|Автор = [[Участник:ArmorAdmin|Чобиток Василий]], 12-14 марта 2009
 
|Источник =
 
|Источник =
 
|Добавил =
 
|Добавил =
−
}}
+
}}<href rel="author" href="https://plus.google.com/107836225500495979443/" target="blank" style="display: none;">G+</href>
 
: ''Здесь собраны и постепенно будут пополняться советы как следует и как не следует работать с заказчиком программного обеспечения''
 
: ''Здесь собраны и постепенно будут пополняться советы как следует и как не следует работать с заказчиком программного обеспечения''
  
Строка 23: Строка 25:
 
А теперь некоторые рекомендации, которых следует придерживаться при работе с заказчиком.
 
А теперь некоторые рекомендации, которых следует придерживаться при работе с заказчиком.
  
−
== Не парь заказчику мозги ==
+
== Говори заказчику правду ==
 +
: ''29.09.2011''
  
−
Заказчик по определению не специалист в области программирования, тем более, в области руководства и аналитики программных проектов. Нет, бывают конечно исключения, но исходить надо из этого — заказчик не знает как правильно разрабатывать программы, но он специалист в своей предметной области (далеко не всегда, к сожалению) и именно этим и должен быть ценен для разработчика и проекта.
+
Заказчик, пользователи в большинстве своём прекрасно всё понимают. Если у проекта есть проблемы, которые в конце-концов отразятся на заказчике, то следует честно и вовремя об этом сказать. Есть мнение, что «Правду говорить легко и приятно». Понятное дело, я не за патологическую правдивость вроде «Девушка, а у вас ноги кривые!» — это, может быть, и правда, но за неё бьют по морде, и правильно.
  
−
Посему, не парь мозги заказчику своими заморочками, связанными с твоим субъективным пониманием того, как правильно писать программы и управлять эти процессом. Да, работать с заказчиком надо постоянно, встречаться как можно чаще но говорить не о будущей программе, а о той подлежащей автоматизации работе, которой он, заказчик, занимается. За первый месяц проекта ты должен стать таким же врачом, каким врач-заказчик стал за пять лет учёбы и десять лет работы; таким же прокурором, каким стал прокурор-заказчик за… и т. д., и т. п.
+
Сколько раз сталкивался с ситуациями, когда при работе с заказчиком специалист вместо того, чтобы говорить правду о проекте, пытался «заниматься маркетингом», для «пользы дела» скрывал реальное положение вещей, пытался всё представить в оранжевом свете. На этого специалиста заказчики смотрели с недоверием и не воспринимали всерьёз, потому что реальное положение вещей они и так прекрасно представляли.
  
−
== Кто делает ТЗ? ==
+
Еще в 1993 году на лекции по «Военной педагогике и психологии» преподаватель рассказал такую байку.
  
−
Извечная проблема связана с тем, кто пишет техническое задание (ТЗ) и разрабатывает требования.  
+
: Шел 1917 год, на фронте с немцами полный развал — целые полки и дивизии бросают фронт и эшелонами едут по домам. Фронт перед немцами оголился, Питер защищать некому. И все политические силы, не смотря на непримиримые разногласия, понимают, что войска любой ценой надо возвращать на фронт. Другое дело, немаловажно под чьими политическими знаменами это произойдет...
 +
: На станции стоят эшелоны покинувшей фронт дивизии.
  
−
Конечно же, ТЗ разработчику '''выдаёт''' заказчик и требования выдвигает он же, что неоспоримо. Однако, это совершенно не означает, что ТЗ заказчик '''пишет'''. Если ты разработчик с опытом, то о ТЗ на программу должен знать всё, ведь сколько проектов ты сделал, столько ТЗ (не меньше) по идее и должно было через тебя пройти. Что знает о ТЗ на программу среднестатистический заказчик? Ровным счётом ничего, он их никогда не писал, не видел, что в них должно быть условно догадывается. Поэтому возьми это на себя — разработчик сделает ТЗ намного быстрее, а пока будет делать, то ещё и получит необходимые знания предметной области. Естественно, писать ТЗ надо максимально привлекая заказчика.
+
: Приезжает к ним парламентер от монархистов.
 +
: — Братцы! Война до победного конца!
 +
: — А что нам за это обещаешь?
 +
: — Победим, восстановим монархию, каждому поле земли, лошадь, по три коровы...
 +
: — О! Ух ты, знатно поёшь. А как насчет баб?
 +
: — Каждому по бабе будет.
 +
: — Знаешь, мил человек, вали нах отседова!
  
−
То же самое и с требованиями. Правильно оформить требования для заказчика проблема. Следуя совету из предыдущего пункта, не надо парить ему мозги, пусть озвучивает свои пожелания к программе, а ты документируй требования за него.
+
: Следующий от кадетов:
 +
: — Десять тыщ рублей золотом каждому!
 +
: — А обмундирование?
 +
: — Много нового обмундирования английского сукна, только со складов, всем хватит!
 +
: — И ты, мил человек, вали нах отседова!
  
−
Оформленные ТЗ и требования (для простых проектов это может быть один документ) обязательно согласовываются и утверждаются заказчиком.
+
: Примерно в том же духе шел разговор и с другими парламентёрами.  
  
−
'''Помни!''' ''Согласованное и утвержденное ТЗ устаревает в момент его утверждения!''
+
: Приезжает комиссар от большевиков.
 +
: — Ты-то что обещаешь? Как насчет денег, земли, баб, обмундирования?
 +
: — А пообещать я могу следующее. Будет холодно, голодно, грязь, в окопах вши и крысы. Пули и смерть. Денег у нас нет, нового обмундирования тоже, оружие то, что при вас, бабы такие же люди и мы их не раздаём. Ещё могу сказать — пустим германца в Питер не будет житья на нашей земле...
  
−
== Сбор и документирование требований ==
+
: Эшелоны поехали в обратную сторону, на фронт.
  
−
Тщательно задокументируй всё то, что заказчик хочет и озвучивает. Дай получившееся ему на подпись и при разработке строго следуй этим требованиям. В результате '''получится полная хрень!'''
+
Большевик ничего хорошего не обещал, только плохое, а пошли за ним. Почему? Очень просто, он сказал правду. Людям настолько много обещали и так много обманывали, что они не верили никаким уговорам, а пошли за теми, кто ничего хорошего не предложил, но сказал правду, ''которая и так была известна этим людям''.
  
−
Не для того ты на этом рынке работаешь и не для того мозги тебе дадены, чтобы так бездарно управлять требованиями.
+
Мне кажется, что подобные поучительные истории современным специалистам с маркетинговым мышлением не рассказывают.
  
−
: ''Подробнее см. «[[Участник:ArmorAdmin/Сбор требований|сбор требований]]»''
+
=== Пример 1. Из моей практики ===
  
−
== Управление ошибками и запросами на изменение ==
+
Несколько лет назад шло внедрение программы «Атлант» в общие суды Украины. Программа на тот момент была в состоянии альфа-теста, требовала от компьютеров пользователей немалые мощности, к инсталляционному пакету программы на несколько десятков гигабайт дополнительно требовался MS .NET Framework, а на многих компьютерах приходилось ещё переустанавливать операционную систему.
  
−
Ошибки бывают разные. К ним относятся как банальные «глюки» — исключительные ситуации, которые не обрабатываются программой, так и несоответствие реализации требованиям. Запросы на изменение — те же требования к программе, только возникшие после разработки определенного функционала, когда стало понятно, что его следует доработать или изменить. Управление теми и другими практически не отличается. Неконтролируемый процесс выявления ошибок и запросов на изменение может привести к колоссальным потерям времени. И тут важно правильно организовать процесс управления ошибками и запросами на изменение.
+
Программа часто тормозила, подвисала, в общем проявляла все прелести программного продукта в состоянии альфа-теста. Причём, из десятков предполагаемых функций программы на тот момент была реализована пока одна. В общем, говорить об удовлетворённости пользователей и хорошем морально-психологическом состоянии сисадминов на местах не приходилось.
  
−
В который раз напомню: заказчик по определению не умеет это делать. Заказчик только может ответить на вопрос, что для него важнее, раньше исправить эту ошибку или внести то изменение, то есть определить приоритеты.
+
Через пару месяцев после эпопеи с установкой программы на компьютеры пользователей по всем судам собираем региональных инженеров на семинар по её использованию.
  
−
И здесь я столкнулся с доведением этого принципа до полного маразма. Разработчики, получив приоритеты, забывают о такой простой вещи, как сложность реализации. Например, все критические замечания (те, без учета которых программа в принципе не работает) ставятся на текущую итерацию, важные на следующую, а необходимые ещё дальше. Вроде бы всё просто, однако заказчик не может понять, почему его элементарная просьба «в этой форме, в этом булевом поле галочку по умолчанию включить» ставится в план на реализацию аж через два месяца (!!!). Почему??? Ведь это же две минуты работы!!!
+
Первое занятие по функционалу провожу я:
  
−
А этот вопрос «почему?» вызывает терпеливое объяснение манагером проекта какой же он сложный этот процесс управления изменениями и как же это важно реализовать по приоритетам, а «галочка» не критична, так как программа и так работает, отвлекать программиста на галочку — потеря времени, а пользователи пусть её два месяца включают. То, что эти два месяца 200 операторов в 95 % из 100 тыс. записей будут лишний раз кликать, чтобы включить «галку» этому, с позволения сказать, манагеру плевать с высокой башни.
+
— Насколько я понимаю, «Атлант» уже все ставили и предварительно ознакамливались с ним?
  
−
Не будь таким же идиотом, как этот манагер. Среди ошибок и запросов на изменение есть элементарные, они вообще не стоят того, чтобы им ставить приоритет. Их просто надо сделать. Сразу. Без обсуждения. Вместе с программистом, за его рабочим местом, пройдись по всему списку и обсуди сложность реализации каждого запроса и те, которые элементарны, программист пусть исправит сразу, мгновенно, без обсуждений, и вычеркнет эти пункты из списка. Таких пунктов, как правило, до половины — потратив два часа работы и сократив список со 100 до 50 позиций вы экономите дни и недели работы, которые были бы потрачены на бесполезное взаимное мозгополоскание якобы процессом управления изменениями. Помни, это не ебля, '''здесь важен не процесс, а результат'''!
+
— Ага... Угу...
  
−
И заказчик будет доволен, он не будет биться в истерике головой ап стену, пытаясь понять, почему «этим идиотам» для замены слова «конь» на «кобыла» в заголовке окна нужен месяц, а чтобы просто «включить галочку» надо с серьезным видом обсудить приоритет, потратив больше времени на обсуждение, чем нужно на саму реализацию, и еще выслушать нотацию этого недоделанного менеджера как важно понимать, что без включенной галочки программа и так будет работать, потому она не критична и её можно сделать позже, для чего этот самый манагер лично запланирует галочку на одну из последующих итераций, обязательно после изменения коня на кобылу и до изменения серого шрифта на светло-сером фоне на черный шрифт…
+
При этом у народа физиономии кислые, как будто они только что от зубного врача вышли. Я прекрасно понимаю их состояние и без слов знаю мнение о нашей программе. Ну, что же, занятия по военной психологии и педагогике мы не зря посещали:
  
−
Не хочешь утонуть в мелочах? Устраняй мелкие проблемы сразу!
+
— Так вот, то что вы увидели сейчас — говно, программа полное фуфло и отстой!
  
−
И ещё раз напомню: '''Не парь заказчику мозги!''' — это не он виноват в том, что ты родился на свет.
+
Лица оживились, глаза круглые, народ таким поворотом событий ошарашен — они ожидали выступление представителя «канадской оптовой компании», расхваливающего свой продукт, а тут такое заявление! Причем, в сказанном для них ничего нового — обыкновенная правдивая констатация факта.
  
−
== Планирование ==
+
После этого я рассказываю, о том, что на самом деле на поверхности пока только одна функция из нескольких десятков, рассказываю о планах того, как мы хотим автоматизировать суды (о реальных планах) и что программа монструозна при мизерном функционале потому, что при разработке архитектуры в неё заранее закладывается фундамент, позволяющий реализовать все те возможности, которые запланированы.
  
−
Вы не задумывались, почему практически любая интеллектуальная деятельность начинается с вопросов общего характера, а потом идет постепенное погружение в детали? Очень просто, если начать с деревьев, то потом можно не увидеть лес. Об этом знали даже наши далёкие предки.
+
Людям ещё ни разу не рассказывали о планах и не пытались говорить с ними правдиво. Увидев понимание проблемы с моей стороны и то, что им говорят правду, а не маркетинговые лозунги, они включились в работу и, не смотря на мой негативный первоначальный отзыв, настроились на позитив.
  
−
Так обучение начинается с вводного курса, а каждое занятие с оглашения темы занятия и списка тех вопросов, которые будут рассмотрены. Проектирование [[танк]]а начинается с общей [[Компоновка|компоновки]] и только потом идет переход к частной компоновке отделений танка, к агрегатам и узлам, размещенным в этих отделениях. Объектно-ориентированный анализ при разработке программ тоже идет от общего к частному, он начинается с декомпозиции. Аналитик в начале витает в облаках (высокие цели проекта), потом спускается до высоты птичьего полета (цели конкретизируются), опускается до уровня моря (задачи высокого уровня, направленные на решение поставленных целей), опускается в морскую пучину до рыбок и далее вниз вплоть до раковин с моллюсками, коих тысячи (конкретные мелкие частные и неделимые задачи).
+
Более того, я рекомендовал инженерам рассказывать о программе на местах примерно то же самое — правду.
  
−
Опять же, любая работа начинается с планирования. А планировать, как это ни грустно звучит, в программной индустрии умеют считанные единицы. Более того, не могу с уверенностью сказать умею ли планировать программные проекты я сам :-)
+
Знаете что? Не смотря на то, что программа и в самом деле была полным отстоем, и её внедрение до того совершенно не клеилось, после этого семинара внедрение пошло как по маслу (почти) — видя текущие проблемы, люди стали понимать их природу, но и перспективу тоже.
  
−
Раз человечество выработало механизм постепенного углубления в проблему «от общего к частному», то стоит ли изменять ему при планировании программных проектов?
+
=== Пример 2. Из моей практики ===
  
−
В [[КТЦ]], где я имел честь служить пять лет, учили создавать ''перспективный план'' части (на пять лет), ''годовой план'' части, годовой план отдела, ''план на тему''<ref>'''Тема''' — то же, что в программной индустрии принято называть проектом.</ref> в целом, ''квартальный план'' темы, ''месячный план'' и вплоть до ''недельного плана'' отдела.
+
Сейчас я отвечаю за [http://wiki.worldoftanks.ru/ вики-проект] прекрасной игры World of Tanks. Буквально вчера [http://worldoftanks.ru/ru/news/1/more_information_about_the_many_claster_technology/ объявили], что с одной из следующих версий игры будет введена поддержка многокластерной технологии, когда один регион (в данном случае русскоязычные игроки) будет обслуживаться несколькими кластерами серверов (сейчас один кластер и он работает на пределе своих возможностей — более 200 тыс. игроков в онлайне одновременно). Причем, многокластерность будет заключаться в том, что при входе в игру игрок сам выбирает, на каком из кластеров играть.  
  
−
Так вот, план темы в целом создавался одновременно с годовым планом. В годовой план попадали макропоказатели планов по каждой теме. Потом план на квартал, потом — на месяц, недельный в конце концов. Каждый план был подробнее и подробнее, и разрабатывался перед началом соответствующего периода. Это и есть декомпозиция. При этом, что вполне очевидно, список всех тех задач уровня моллюсков, которые появлялись в месячных и недельных планах, изначально не был известен.
+
Это решение не понравилось очень многим игрокам, они не хотят разделяться по разным «квартирам». Более того, ряд игроков, разбирающихся в архитектуре подобных систем, высказали мнение, что по-хорошему надо было бы автоматически подключать игрока к менее нагруженному и доступному по пингу кластеру; а при необходимости — автоматически перебрасывать с одного кластера на другой. Ведь пользователь не выбирает сервер в кластере, так почему бы точно так же не заставлять его выбирать кластер?
  
−
Так может быть такое планирование не было точным? Оно было точным и по результатам выполнения темы отклонение в часах на 10 % от первоначального плана уже считалось большим. Да, бывали и переносы на другой период, если заказчик не смог вовремя предоставить исходные материалы, бывали увеличения плановых показателей, если по ходу выяснялось, что заказчику требуется больше, чем изначально планировалось. Но на каждые десять тем таких было не больше одной-двух. То есть методы планирования, которые использовали наши отцы и деды, работают! Планировать надо от общего к частному, но не в иную сторону!
+
Казалось бы, причем здесь работа с заказчиком?
  
−
Зачем я так подробно остановился на том, как было в КТЦ? Уже не раз сталкивался с идиотским посылом среди манагеров новой формации, что «пока мы не распишем все задачи (вплоть до каждого моллюска), план на проект выдать не можем».
+
Приведу несколько цитат из объявления:
  
−
Это порочный подход, и вот почему. Допустим, что в начале проекта тебе о проекте известно буквально всё (хотя, так не бывает, по определению, никогда) и ты длинный список частных задач выдал программеру. Например, он, оценивая каждую задачу, ошибается в два раза (вместо двух дней у него один, вместо месяца — две недели). Просто потому, что ему впадлу показаться недотёпой, который медленно работает. Кроме того, оценка каждой такой задачи в начале проекта в любом случае не учитывает многие изначально неизвестные факторы, которые проявятся позже. Итого, вместо например года мы получаем полгода…
+
;Цитата 1
 +
: ''Работа, проводимая нашими специалистами в данном направлении, призвана значительно расширить игровые мощности и сделать игру в World of Tanks максимально комфортабельной.''
  
−
Как же быть? Ведь ты не первый день на рынке, уже делал какие-то проекты, их планировал и твой первоначальный план был один, а итоговое время получилось совсем иным. Вот и оцени проект в целом по аналогии с предыдущими.
+
;Цитата 2
 +
: ''Использование нескольких кластеров для одного региона обеспечит дополнительные возможности:''
 +
:* ''максимальное количество активных игроков в данном регионе значительно возрастет (игроки будут распределены по нескольким кластерам);''
 +
:* ''игроки смогут выбирать тот кластер, который обеспечивает максимальный комфорт игры (например, кластер с лучшей связью и минимальной загрузкой);''
 +
:* ''игроки в любой момент смогут переключиться на другой кластер ради новых ощущений;''
 +
:* ''в случае проведения технических работ или неполадок на одном из кластеров, игроки смогут переключиться на работоспособный кластер.''
  
−
А еще, открою секрет, у заказчика есть свои сроки. Но это не абстракции, как у разработчика. Например, с 1 апреля по закону о резинотехнических изделиях необходимо организовать строгий номерной учёт выданных резинок. Планируй что хочешь и как хочешь, а появиться вечером 31 марта и радостно сообщить, что усё готово, это — провал. То есть за месяц, 1 марта, должно было начаться обучение операторов; ещё за месяц до того программа должна была пройти приёмо-сдаточные испытания; ещё за месяц до того заказчик должен был увидеть стабильную версию программы, кандидат на выпуск; а периодически до того он должен был бы видеть и промежуточные версии, чтобы понимать, как идет проект.
+
Что мы видим? Это писал человек с маркетинговым мышлением и здесь не правда, а сплошной маркетинг.
  
−
== Риски ==
+
Почему?
  
−
Управление рисками должно быть. Предсказанная проблема — первый шаг к её избежанию.  
+
Потому что 400 тыс. игроков вместо 200 тыс., для меня, как для игрока, не новая возможность. Когда в бою 30 чел. и не более, мне совершенно пофиг в онлайне 10 тыс. или 400 тыс.
  
−
Если проблема маловероятна и устранима за полдня в случае наступления, вообще не стоит заранее на неё заморачиваться.
+
Возможность выбирать кластер... Это не возможность, это лишний функционал на стороне пользователя и лишний ему геморрой.
  
−
Не подменяй управление рисками прикрывательством собственной жопы.
+
Переключиться на другой кластер ради «новых ощущений» может только клинический идиот — всё так же случайно подобраны игроки в команды случайных боёв, все те же партнёры в ротных боях. В чём новые ощущения?
 +
 
 +
Точно так же переключать на другой кластер при технических работах можно было бы автоматически и это тоже не новая возможность, а новый геморрой.
 +
 
 +
Вполне закономерно, что этот «маркетинг» вызвал бурю эмоций на форуме, игроки просто «срут кирпичами»!
 +
 
 +
И среди сотен постингов SerB (главный гейм-дизайнер) на очередное предложение сделать работу кластеров автоматической и скрытой от пользователей ответил: «''Это было бы идеальным вариантом. Однако по ряду архитектурных и технических причин такое пока невозможно. По крайней мере, в требуемые нам сроки.''»
 +
 
 +
Вот '''правда''', она проста и понятна. И что мешало именно об этом написать в объявлении? — наплыв игроков требует кардинальных и срочных мер, есть хорошие решения, но они нереализуемы в приемлемые сроки, поэтому за основу взято не самое удачное, но реализуемое.
 +
 
 +
Спрашивается, кто был бы недоволен, если вместо «маркетинга» пользователям была бы сказана правда? Игроки отнеслись бы с пониманием и способности самих разработчиков не подвергались сомнению.
 +
 
 +
: '''Разработчик! Пользователь не враг твой, говори ему правду.'''
 +
 
 +
== Что хочет <s>Бог</s> Заказчик? ==
 +
: ''22.06.2010''
 +
 
 +
[[Файл:Legion.jpg|thumb|Архангел Михаил знает, что нужно заказчику, он — правильный аналитик]]
 +
Только ради этого диалога в конце фильма:
 +
 
 +
: '''Архангел Гавриил:''' Не может быть! Ты же ослушался Его!
 +
: '''Архангел Михаил:''' Ты дал Ему то, что Он просил… Я — то, что Ему было нужно.
 +
 
 +
стоит посмотреть «Легион» (2010 год).
 +
 
 +
: Уж сколько раз твердили миру, <br />что можно угодить заказчику не выполнением указаний, <br />а токмо удовлетворением его потребностей. <br />Но грабли не новы, а воз и ныне там… <span style="font-size:smaller;">(прошу простить за вольности в пересказе дедушки Крылова)</span>
 +
 
 +
== Не парь заказчику мозги ==
 +
: ''12.03.2009''
 +
[[Изображение:Ia.jpg|thumb|Удовлетворённый заказчик]]
 +
Заказчик по определению не специалист в области программирования, тем более, в области руководства и аналитики программных проектов. Нет, бывают конечно исключения, но исходить надо из этого — заказчик не знает как правильно разрабатывать программы, но он специалист в своей предметной области (далеко не всегда, к сожалению) и именно этим и должен быть ценен для разработчика и проекта.
 +
 
 +
Посему, не парь мозги заказчику своими заморочками, связанными с твоим субъективным пониманием того, как правильно писать программы и управлять эти процессом. Да, работать с заказчиком надо постоянно, встречаться как можно чаще но говорить не о будущей программе, а о той подлежащей автоматизации работе, которой он, заказчик, занимается. За первый месяц проекта ты должен стать таким же врачом, каким врач-заказчик стал за пять лет учёбы и десять лет работы; таким же прокурором, каким стал прокурор-заказчик за… и т. д., и т. п.
 +
 
 +
== Кто делает ТЗ? ==
 +
: ''13.03.2009''
 +
 
 +
[[Изображение:Ideal tz.jpg|thumb|Идеальное ТЗ существует]]
 +
Извечная проблема связана с тем, кто пишет техническое задание (ТЗ) и разрабатывает требования.
 +
 
 +
Конечно же, ТЗ разработчику '''выдаёт''' заказчик и требования выдвигает он же, что неоспоримо. Однако, это совершенно не означает, что ТЗ заказчик '''пишет'''. Если ты разработчик с опытом, то о ТЗ на программу должен знать всё, ведь сколько проектов ты сделал, столько ТЗ (не меньше) по идее и должно было через тебя пройти. Что знает о ТЗ на программу среднестатистический заказчик? Ровным счётом ничего, он их никогда не писал, не видел, что в них должно быть условно догадывается. Поэтому возьми это на себя — разработчик сделает ТЗ намного быстрее, а пока будет делать, то ещё и получит необходимые знания предметной области. Естественно, писать ТЗ надо максимально привлекая заказчика.
 +
 
 +
То же самое и с требованиями. Правильно оформить требования для заказчика проблема. Следуя совету из предыдущего пункта, не надо парить ему мозги, пусть озвучивает свои пожелания к программе, а ты документируй требования за него.
 +
 
 +
Оформленные ТЗ и требования (для простых проектов это может быть один документ) обязательно согласовываются и утверждаются заказчиком.
 +
 
 +
'''Помни!''' ''Согласованное и утвержденное ТЗ устаревает в момент его утверждения!''
 +
 
 +
== Сбор и документирование требований ==
 +
: ''14.03.2009''
 +
: ''Подробнее см. «[[Участник:ArmorAdmin/Сбор требований|сбор требований]]»''
 +
 
 +
=== Строгое следование спецификациям ===
 +
 
 +
Тщательно задокументируй всё то, что заказчик хочет и озвучивает. Дай получившееся ему на подпись и при разработке строго следуй этим требованиям. В результате '''получится полная хрень!'''
 +
 
 +
Не для того ты на этом рынке работаешь и не для того мозги тебе дадены, чтобы так бездарно управлять требованиями.
 +
 
 +
=== Задавай правильные вопросы ===
 +
 
 +
Чтобы продукт получился, он должен решать определенные цели, потребности клиента. Поэтому неуместны вопросы, которые обычно задают аналитики: «''Что ты хочешь?''», а еще хуже — «''Как ты хочешь?''»
 +
 
 +
Уместным является вопрос именно о целях. Однако, если так и попросить «Сообщи цели», то заказчик, скорее всего, впадет в ступор, ему будет сложно вот так сразу взять и определить цели — это слишком высокие материи… Поэтому наилучшим есть вопрос «'''''Зачем''' тебе это нужно?''» — понятно и на такой вопрос легко отвечать, если человек что-то хочет, он сможет объяснить зачем ему это нужно (а это и есть его цель, реальная потребность).
 +
 
 +
== Управление ошибками и запросами на изменение ==
 +
: ''26.05.2009''
 +
 
 +
Ошибки бывают разные. К ним относятся как банальные «глюки» — исключительные ситуации, которые не обрабатываются программой, так и несоответствие реализации требованиям. Запросы на изменение — те же требования к программе, только возникшие после разработки определенного функционала, когда стало понятно, что его следует доработать или изменить. Управление теми и другими практически не отличается. Неконтролируемый процесс выявления ошибок и запросов на изменение может привести к колоссальным потерям времени. И тут важно правильно организовать процесс управления ошибками и запросами на изменение.
 +
 
 +
В который раз напомню: заказчик по определению не умеет это делать. Заказчик только может ответить на вопрос, что для него важнее, раньше исправить эту ошибку или внести то изменение, то есть определить приоритеты.
 +
 
 +
И здесь я столкнулся с доведением этого принципа до полного маразма. Разработчики, получив приоритеты, забывают о такой простой вещи, как сложность реализации. Например, все критические замечания (те, без учета которых программа в принципе не работает) ставятся на текущую итерацию, важные на следующую, а полезные ещё дальше. Вроде бы всё просто, однако заказчик не может понять, почему его элементарная просьба «в этой форме, в этом булевом поле галочку по умолчанию включить» ставится в план на реализацию аж через два месяца (!!!). Почему??? Ведь это же две минуты работы!!!
 +
 
 +
А этот вопрос «почему?» вызывает терпеливое объяснение манагером проекта какой же он сложный этот процесс управления изменениями и как же это важно реализовать по приоритетам, а «галочка» не критична, так как программа и так работает, отвлекать программиста на галочку — потеря времени, а пользователи пусть её два месяца включают. То, что эти два месяца 200 операторов в 95 % из 100 тыс. записей будут лишний раз кликать, чтобы включить «галку» этому, с позволения сказать, манагеру плевать с высокой башни.
 +
 
 +
Не будь таким же идиотом, как этот манагер. Среди ошибок и запросов на изменение есть элементарные, они вообще не стоят того, чтобы им ставить приоритет. Их просто надо сделать. Сразу. Без обсуждения. Вместе с программистом, за его рабочим местом, пройдись по всему списку и обсуди сложность реализации каждого запроса и те, которые элементарны, программист пусть исправит сразу, мгновенно, без обсуждений, и вычеркнет эти пункты из списка. Таких пунктов, как правило, до половины — потратив два часа работы и сократив список со 100 до 50 позиций вы экономите дни и недели работы, которые были бы потрачены на бесполезное взаимное мозгополоскание якобы процессом управления изменениями. Помни, это не ебля, '''здесь важен не процесс, а результат'''! Естественно, вычеркнутые пункты можно сразу же сообщить тестировщику для их немедленной проверки.
 +
 
 +
И заказчик будет удовлетворён, он не будет биться в истерике головой ап стену, пытаясь понять, почему «этим идиотам» для замены слова «конь» на «кобыла» в заголовке окна нужен месяц, а чтобы просто «включить галочку» надо с серьезным видом обсудить приоритет, потратив больше времени на обсуждение, чем нужно на саму реализацию, и еще выслушать нотацию этого недоделанного менеджера как важно понимать, что без включенной галочки программа и так будет работать, потому она не критична и её можно сделать позже, для чего этот самый манагер лично запланирует галочку на одну из последующих итераций, обязательно после изменения коня на кобылу и до изменения серого шрифта на светло-сером фоне на черный…
 +
 
 +
Не хочешь утонуть в мелочах? Устраняй мелкие проблемы не отходя от кассы!
 +
 
 +
И ещё раз напомню: '''Не парь заказчику мозги!''' — это не он виноват в том, что ты не умеешь работать.
  
 
== Не хами! ==
 
== Не хами! ==
 +
: ''27.05.2009''
  
 
Конечно, не нужно целовать заказчика в обе ягодицы только потому, что он платит деньги. Однако, его следует уважать и не следует ему хамить.  
 
Конечно, не нужно целовать заказчика в обе ягодицы только потому, что он платит деньги. Однако, его следует уважать и не следует ему хамить.  
Строка 111: Строка 215:
  
 
После выяснения обстоятельств, оказалось: результаты поиска действительно выглядели неадекватными, что вызвало вполне закономерные вопросы. Вместо пояснения сути проблемы высказывать «автор вопроса не понимает» — хуже чем хамство, это мудачество. Следует понимать, что общаться с мудаком намного неприятнее, чем с хамом.
 
После выяснения обстоятельств, оказалось: результаты поиска действительно выглядели неадекватными, что вызвало вполне закономерные вопросы. Вместо пояснения сути проблемы высказывать «автор вопроса не понимает» — хуже чем хамство, это мудачество. Следует понимать, что общаться с мудаком намного неприятнее, чем с хамом.
−
 
−
== Примечания ==
 
−
 
−
<references />
 
  
 
== Ссылки ==
 
== Ссылки ==
−
* [http://agilemanifesto.org/ Manifesto for Agile Software Development]
+
* [[Участник:ArmorAdmin/Гибкие_методы_разработки|Manifesto for Agile Software Development]] (Манифест гибкой методологии разработки)
  
−
[[Категория:Личные заметки]]
+
[[Категория:Личные заметки|Работа с заказчиком]]
 +
[[Категория:Программная инженерия|Работа с заказчиком]]

Текущая версия на 05:47, 20 декабря 2015

«Предоплата ускоряет выполнение всех Ваших прихотей!» — это текст на плакате при входе к тебе в офис.


Автор(ы): Чобиток Василий, 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» выдал так много результатов. После разборок оказалось, что результат поиска правильный, просто автор вопроса не понимает, что такое контекстный поиск.

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

Ссылки

Источник — «http://armor.kiev.ua/wiki/index.php?title=Участник:ArmorAdmin/Работа_с_заказчиком&oldid=12346»