Часто разработчики говорят мне, что soft skills им не нужны. Разработчик — не менеджер и управленческие навыки может не развивать. С одной стороны так и есть — разработчику очень важно углублять свои знания в технологиях и методологиях проектирования ПО. С другой стоны, я уверен, каждому хочется уметь отстаивать свою позицию и получать заслуженную похвалу за хорошую работу. А если так, то почему бы не продвинуться в этом направлении? 

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

Под «заказчиком» я имею ввиду любые отношения заказчик-исполнитель, где вы являетесь исполнителем. Заказчиками могут быть пользователи вашего продукта, может быть Project Manager, может быть совет директоров, может быть бухгалтер из соседнего отдела и т.д.

Всё, о чём будет идти речь, точно сработает, если вы действительно хорошо сделали свою работу. Мы не будем рассматривать случаи, когда качество работы низкое и стоит задача убедить заказчика в обратном.

Ниже слайды и видео с конференции, где эта тема обсуждалась:

На выступлениях не удалось полностью раскрыть часть тем. Дальше статья с более подробными комментариями и ссылками.

Когда возникают проблемы?

Как часто бывает, что вы написали отличный код, решили задачу, а заказчик недоволен? Лично я в такие моменты думаю, что потратил силы, но не получил никакой отдачи.

Или такая ситуация: Вам дали систему, которая работает на костылях, попросили исправить несколько багов. Вы обнаружили в системе множество проблем, убрали весь г@внокод, заставили систему работать, буквально совершили чудо. Оказалось, что до ваших исправлений она в принципе не работала, но заказчик об этом не знал. В итоге, заказчик предъявляет вам претензии из-за низкой скорости работы — он не понимает как можно было так долго исправлять несколько ошибок.

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

Во всех этих случая мы с одной стороны написали качественный рабочий код, но чего-то не хватило, чтобы результат был оценён заказчиком по достоинству. Если хотите, то у нас не получилось «продать» результат заказчику.

Визуализация

Одна из ключевых практик в Kanban — это визуализация работы: «You cannot improve what you cannot see». Следующие три подхода нацелены на визуализацию целей проекта, задач и текущего процесса.

Понимаем цели через Impact Mapping

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

Impact Mapping простая и эффективная техника для определения целей заказчика и передача этих целей разработчикам. Для средних размеров проекта (полгода работы) составление карты занимает от 2 до 6 часов.

Недавно я подробно описывал, как мы применяем Impact Mapping на практике. Здесь повторяться не буду, а только вынесу несколько интересных вопросов из конференций, которые мне задавали участники:

• Q: Как уговорить заказчика заниматься Impact Mapping'ом? Особенно инетресно работает ли это для государственных заказчиков?
  
  A: Как всегда начните с проблемы. Был ли у заказчика неудачный опыт, когда он написал детальное ТЗ, а в результате получил не то, что хотел? Нужно показать, что есть такая проблема и предложить Impact Mapping в качестве решения. С гос. заказчиками это работает точно также. Среди гос. заказов бывают разные, там главное найти человека, которому действительно нужен этот проект и сделать с ним Impact Mapping. Если проект (коммерческий или гос.) делается для галочки, то маппинг лучше не делать, ни к чему время тратить.

• Q: Мы хотим узнать проблему, настроиться на волну заказчика и постоянно спрашиваем Почему, Почему и т.п.? А конкуренты не спрашивают, они берут ТЗ и делают, что им сказали или пытаются угадать. Как не спугнуть заказчика своими постоянными распросами и новыми техниками?
  
  A: Ответ аналогичный прошлому. Начните с объяснения проблемы. Если заказчик отказывается и не понимает зачем делать Impact Mapping, то может и не стоит его делать. По опыту могу сказать, что зрелые заказчики никогда не отказываются от этой практики, т.к. его польза для проекта очевидна.

• Q: Пришёл заказчик, который хочет заказать веб-проект. Разобрали цели и вместе поняли, что для достижения целей веб-проект не нужен. Обидно терять заказчика. Как быть?
  
  A: Это моральный выбор каждого. Можно показать заказчику другие пути развития его бизнеса, в которых вы не участвуете. Он будет вам благодарен и возможно вернется снова. Если боятся того, что после Impact Mapping вы окажетесь не нужны, то лучше его не делать, но и на хороший результат расчитывать не стоит.

• Q: Что если в начале проекта сделали Impact Mapping, определили цели проекта, а в конце проекта поняли, что цели не достигнуты?
  
  A: Постановка целей — это эксперемент, все могут ошибаться. Важно как можно быстрее понять, что целей мы не достигаем и изменить маршрут. Для этого необходимы частые релизы и сбор обратной связи.

Story Mapping

После определения карты влияний на цели можно определить роли пользователей, как они будут взаимодействовать с системой, важность задач, план релизов и т.д. Для этого мы делаем Story Mapping.

В ТЗ нет объема и динамики, нет приоритетов, его не достаточно, чтобы понять масштабы проекта.

Здесь я не буду подробно расписывать нюансы этой техники, могу только порекомендовать статью The new user story backlog is a map и книжку User Story Mapping: Discover the Whole Story, Build the Right Product. Кроме того, Story Mapping рассматривается почти в каждой книге про гибкое управление проектами.

Важная рекомендация: На Story Mapping обязательно берите с собой UI/UX специалиста, который будет заниматься проектом. Он должен критически смотреть на все User Story и фильтровать поток мыслей от заказчика.

В качестве реального примера фотография из нашего офиса, на ней Story Map для первой версии продукта. Объём работы примерно на 4 месяца для команды из 5 человек. Составление карты заняло 5 часов. Участвовали 3 представителя заказчика, 3 разработчика.

Kanban-доска

После того, как мы спланировали работу, начинаем визуализировать процесс разработки на доске. На данный момент Kanban-доска, пожалуй, один из самых популярных инструментов. Про доску написано много и в книгах про Scrum, и в книгах про Kanban, и в других источниках про Agile и Lean.

Здесь я хочу отметить только одну важную деталь, на которую не многие обращают внимание. Скажите, как называется ваш последний столбец на доске? Могу предположить, что он называется Closed, Release, Production или что-то в этом духе. На самом деле Impact Mapping подсказывает нам, что последний столбец это не выкладка фичи в релиз, это проверка достижения цели. Мы брали фичу в работу, исходя из того, что она повлияет на достижение цели, так почему бы в конце это не проверить?

Визуализации много не бывает

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

Для начала хочу отметить, что разработка ПО сложная штука и является прежде всего «knowledge work». Если мы правильно поняли цели проекта, правильно определили приоритеты и можем постоянно оптимизировать процесс разработки, то у нас появляется 8 шансов из 10 сделать нужный продукт/проект. Попытка делать эти маппинги и визуализация работы на доске — это способ разъяснять самим себе и заказчику суть решаемых задач.

Надеюсь вы согласитесь с моим предыдущим тезисом. Если да, то надо понимать, что маппингов много не бывает. Их значимость для проекта трудно переоценить.

На сколько затратно поддерживать это всё в актуальном состоянии? Как работать с изменениями, которые в любом случае будут происходить? Исходя из практики, могу сказать, что Impact Mapping довольно редко меняется и пересматривается. Обычно не чаще, чем выходят мажорные релизы, а то и реже. Чуть чаще обновляется Story Mapping. Ежедневно нам надо обновлять только доску, а это не занимает много сил и времени. Обновление статуса задач на стендапе довольно веселая и простая практика. В любом случае польза от визуализации нашей работы перевешивает затратры на их создание и поддержание.

Доверие и прозрачность

Есть отличная статья Управленческие инструменты: Почему заказчики требуют дурацкие отчеты? от компании Stratoplan. Рекомендую прочитать саму статью, а здесь я коротко опишу как мы используем матрицу 2×2 в своей работе.

У нас получилось 4 сектора с разными уровнями доверия и прозрачности. Как вы думаете, в каком из квадратов лучше всего находиться? Скорее всего вы скажете C или D, где доверие к нам высокое. Если доверие к нам, как к профессионалам, высокое, то это даёт большую свободу и ответственность. Если же у заказчика к нам низкое доверие, то скорее всего заказчик пытается много контроллировать: мы пишем детальные отчеты по каждому движению, спорим по вопросам, которые должны быть в границах нашей компетенции и т.п. Всё это рождает проблемы и замедляет развитие проекта.

Давайте рассмотрим в динамике как мы будем двигаться к высокому доверию со стороны заказчика:

1. Изначально, скорее всего, мы находимся в квадрате А — низкое доверие и низкая прозрачность процессов. Даже если заказчик говорит, что верит вам как себе, всё равно вы с ним ещё не работали и по факту он вам не доверяет. Из квадрата А мы начнём двигаться в сторону С, но как это сделать? Прыгнуть сразу в С вряд ли получится, доверие не рождается на ровном месте. Наш способ повышения доверия будет связан с повышением прозрачности процессов, т.е. мы выбираем путь A → B → C.

2. Чтобы прозрачность повысилась мы можем: делать Impact Mapping, делать Story Mapping, визуализировать текущую работу на Kanban-доске, каждый день делать стендапы, проводить демо и ретроспективы, делать частые релизы и т.д. Любыми способами стараемся повышать прозрачность нашей работы.

3. Если удалось повысить прозрачность, то мы переходим в квадрат В (низкое доверие и высокая прозрачность) — заказчик начал понимать Что, Как и Почемупроисходит на проекте. У заказчика возникает чувство контроля над процессом, причём инициатива на нашей стороне, за счёт этого постепенно повышается и доверие.

4. Время перехода B → С (прозрачность высокая и доверие высокое) всегда разное, но по опыту могу сказать, что оно занимает обычно 2-4 месяца. Работа в квадрате С требует с нашей стороны значительных усилий, но за это мы получаем высокую лояльность заказчика.

5. В этот момент происходит странная штука — команды начинают расслабляться, причем как разработчики, так и заказчики. Заказчики могут перестать приходить на демо. А зачем? Там и так всегда всё классно. Заказчики могут начать игнорировать планирования, ведь разработчики понимают куда идёт проект и что сейчас важно. Разработчики со своей стороны перестают делать ежедневные релизы, проводить ретро и т.п.

6. Со временем мы уходим из С в квадрат D. Доверие со стороны заказчика высокое, но такой прозрачности как раньше уже нет. Такое положение дел очень удобно для всех сторон.

7. Чем опасен квадрат D? Представьте себе, что вы находитесь в D и произошла какая-то серьезная проблема. Раньше для заказчика всё было прозрачно и можно было отследить корень проблемы, теперь мы просто в хороших отношениях с высоким уровнем доверия. Достаточно одной серьезной проблемы или ряд проблем, чтобы вы перешли из D сразу в А. Прозрачности процессов уже нет, все расслабились и доверие резко упало. Отсюда нам придется проделать весь пусть снова и начать работу по переходу в С через В. Есть оптимистчиная стрелка из А обрато в D, но в реальности я не видел, чтобы так было.

Что делать, если мы находимся в квадрете С и заметили, что все начали расслабляться? Надо любыми способами удержаться в С, т.к. квадрат D — это довольно нестабильное состояние. Если заказчик не ходит не демо и планирование, то сами присылайте ему отчеты с результатами работы, отчеты о проделанной работе, рассказывайте о проблемах и достижениях. Если разработчики перестали вкладывать силы в поддержание прозрачности процесса, то обратите их внимание на возможные проблемы в будующем, покажите эту матрицу и ваше текущее положение в ней. Другими словами — не давайте прозрачности снижаться.

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

Все программисты — оптимисты

Ничего не раздражает заказчика больше, чем неверная оценка сроков. Ничего не делает давление на разработчика сильнее, чем неправильно оценненная задача. Причем со временем развития IT-отрасли мало что меняется. Вот цитата из классической книжки Мифический человеко-месяц, которая была выпущена около 40 лет назад:

Возможно, эта современная разновидность колдовства особенно привлекательна для тех, кто верит в хэппи-энды и добрых фей. Возможно, сотни неудач отталкивают всех, кроме тех, кто привык сосредоточиваться на конечной цели. А может быть, дело всего лишь в том, что компьютеры и программисты молоды, а молодости свойствен оптимизм. Как бы то ни было, в результате одно: «На этот раз она точно пойдет!» Или : «Я только что выявил последнюю ошибку!»

Итак, в основе планирования разработки программ лежит ложное допущение, что все будет хорошо, т.е. каждая задача займет столько времени, сколько «должна» занять. © Брукс

С тех пор, как мы видим, ситуация не изменилась. Программистам хочется выглядеть перед заказчиком профессионалами высшей категории, из-за этого оценки даются оптимистичные. Бывает, что заказчики играют на этой черте программистов и прибегают к разным уловкам. Например, заказчик начинает спрашивать у разработчиков:

— За сколько мы успеем сделать Х?

— За месяц успеем точно

— А что надо сделать, чтобы в неделю уложиться?

— В неделю почти нереально. Можно вот эту часть проще сделать, вот это убрать, тогда и за неделю уложимся

— А за 3 дня справитесь?

— За 3 дня вообще никак, самый предел это 4 дня и ни днем меньше!

— Ну вы, парни, прямо удивили меня! Договорились, 4 дня, начинаем

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

Как же всё-таки оценивать задачи, чтобы всем было хорошо? В прекрасном докладе 36 от Вадима Макишвили есть интересное объяснение, почему и как надо давать оценку:

Представьте себе точку начала проекта и точку окончания. Программист проводит между ними прямую линию, длина линии будет самой оптимистичной оценкой. Проекты практически никогда по прямой линии не идут, а идут хотя бы по окружности. Получается, что нашу оценку надо умножить на π и к результату прибавить 2 недели. Почему плюс 2 недели? Потому что, если за время, отведенное на проект, вы вообще ничего не делали, то за 2 недели можно накидать почти любую систему.

Это, конечно, полу-шуточное объяснение принципа оценки проекта, но оно отлично показывает, что проекты никогда не идут по оптимистичному пути, всегда возникают проблемы и этот факт надо учитывать.

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

Проблем быть не должно

Как однажды сказал Сергей Архипенков: «Если у проекта нет проблем, значит он умер». Проблемы при разработке ПО есть всегда. С другой стороны, заказчика нужно оградить от лишней головной боли, для него проблем быть не должно. Здесь главный вопрос в том, как эти проблемы преподносить заказчику?

Известны случаи, когда разработчики каждое утро присылали заказчику список проблем с надеждой, что он их решит. Так они и работали, но совсем недолго и завершили работу в плохих отношениях.

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

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

2. Придумать варианты решений внутри команды разработки

3. Каждый вариант решения должен иметь описание плюсов и минусов относительно других вариантов

4. Каждый вариант решения должен иметь список рисков, а каждый риск список мер, которые этот риск снижают

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

Заказчик может ошибаться

Что если вы предложили проработанное решение, но заказик настаивает на своём? При этом вы знаете, что решение заказчика ошибочное. Это может касаться любого аспекта разработки: архитектуры системы, инфраструктуры, командообразования и т.п. У нас есть 3 принципиальных варианта выхода из этой ситуации:

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

2. Категорически не согласиться с решением заказчика, т.к. вы знаете, что окажетесь в проблемной ситуации. При этом возможен конфликт, где каждый останется при своем мнении.

3. Детально разобрать решение, которое предлагает заказчик, т.е. расписать плюсы и минусы, риски и варианты снижения этих рисков. В качестве примера рассмотрим ситуацию, когда заказчик не хочет делать Impact Mapping для определения целей проекта, вместо этого он хочет просто прислать вам ТЗ. Можно сказать, что: мы не понимаем целей проекта, можем сделать что-то что не принесет денег и т.п. Если после этих объяснений заказчик всё равно настаивает на своём, т.е. берёт ответственность за эти явно описанные риски на себя, то можно с чистой совестью брать задачу в работу. Сохраните список проблем и рисков под рукой, они вам ещё пригодятся на ретроспективе при разборе ошибочного решения.

Я всегда стараюсь действовать в рамках 3-го варианта, т.к. явно описываются последствия для заказчика, идет попытка понять его решение. Первые два решения оставляют нас в однобокой и закрытой позиции.

Используем domain driven design

В Domain Driven Design есть много аспектов связанных с кодом, шаблонами и подходами к проектированию ПО. Это всё правильно и полезно, но вряд ли заказчик оценит то, что вы выделили функцию без side effects в Value Object и покрыли её тестами. Зато заказчику точно будут интересны и важны части DDD, которые связаны с поставкой продукта и коммуникацией. Я собрал основные моменты, которые помогают программистам наладить общение с заказчиком и создать эффективную модель предметной области в коде:

• Единый язык (Ubiquitous Language) — название переменных, таблиц, названия кнопок в макетах, общение с заказчиком, всё это можно быть только на языке заказчика. Если у заказчика в бизнесе есть термин Агент, в коде он может называться только Agent. Если вы в коде начнёте называть его Customer, Contractor или еще как-то, то при общении с заказчиком будете называть его агентов своими «кастомерами». Со временем заказчику понадобится переводчик, чтобы понимать ваши термины, которыми вы называли его родные бизнес-сущности. Несколько примеров и описание проблемы можно посмотреть в статье Ubiquitous Language и Bounded Context в DDD.

• Модель предметной области (Domain Model) — из единого языка рождается модель предметной области, которая должна быть явно обозначена в коде. Это не анемичная модель, у неё есть поведение, как и у реальных объектов в бизнесе. Доменная модель выражает саму суть бизнеса, она должна быть собрана в одном месте, а не размазана по всему коду проекта.

• Углубленный рефакторинг (Refactoring toward deeper insight) — для создания модели предметной области в объектном анализе рекомендуют из общения с заказчиком, из ТЗ и других источников выделить существительные и глаголы, после чего сделать из них объекты и методы. Наивно полагать, что ваше знание предметной области будет достаточно хорошим, чтобы с первого раза постороить стоящую модель. С погружением в проект, с углублением вашего понимания бизнеса заказчика необходимо совершенствовать и модель.

• Дистиляция модели — для лучшей выразительности из Core Domain нужно убирать всё лишнее, например, выносить части не характерных только для вашей предметной области в Generic Subdomain. В конечном счёте Core Domain проекта является его конкурентным преимуществом, всё остальное можно взять в готовом виде, адаптировать из открытых источников или отдать на аутсорс.

• Ограниченные контекст (Bounded Context) — в подобластях одной отрасли (и одного бизнеса) могут складываться свои термины, даже для одних и тех же понятий. Их унификации — это компромисс. Если вы пойдете на него, то не получите выразительной модели ни в одной из подобластей. Обычно говорят, что модель применима в определенном контексте, причём внутри этого контекста термины модели имеют конкретный чёткий смысл.

Часть подходов, которые описаны в книгах можно попробовать только на проекте, который идет несколько лет. Часть подходов это не конкретные шаблоны, а скорее философия работы с требованиями, принципы выстраивания отношений между командой и заказчиками. Тема DDD довольно большая, но изучать её нужно обязательно. Могу рекомендовать две книги для погружения в тему:

1. Классическая книга от Эрика Эванса Domain-Driven Design: Tackling Complexity in the Heart of Software

2. Более зрелая книга с большим количеством конкретных примеров наработанных сообществом Implementing Domain-Driven Design

Не все заказчики одинаково полезны

Надо отметить, что заказчики бывают разные. Не от всех стоит ожидать радости по поводу высокого качества работы. В некоторых случаях ваши старания в принципе никто не собирается ценить. Несколько полу-юмористических случаев из не-IT, которые можно спроецировать на нашу работу:

У платного врача:

— Вы знаете, я, пожалуй, не буду платить за прием. Как-то мне диагноз не понравился. Изюминки нет, понимаете ли.

В диагностической лаборатории:

— Почему я должен платить за анализ вперед? А если вы ничего не найдете?

В туристической фирме:

— Нет, вы меня сначала свозите в несколько отелей, покажите, дайте выбрать. Тогда и решим.

В магазине:

— Я вот тут бутылку минералки купил у вас. Налил, отпил и внезапно понял, что минералки я сегодня не хочу. Поменяйте ее на квас. Какие деньги? Я же напиток оплатил!

В ресторане:

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

С такими заказчиками лучше даже не начинать работу, ничего хорошего не произойдёт. Но если работать приходится, то заранее откажитесь от идеи, что вам скажут простое человеческое спасибо.

Делимся своим опытом

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