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

Сначала непонятное

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

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

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

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

Важна дисциплина

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

Почему так получалось и какие есть решения.

1. Ошибались в оценках. Как можно было решить эту проблему: оценивать задачи не одним разработчиком, а командой (у нас был один, храни господь его душу), сильнее детализировать большие задачи.

2. Было недостаточно контроля. Это функция управления. Мне известна пара решений: назначение контрольных точек, регулярные собрания и более плотная командная работа при обсуждении бэклога. Важно, чтобы каждый почувствовал свой вклад, проговорил задачи сам и не было ощущения «спустили сверху».

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

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

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

Баги копятся

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

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

Презентации облегчают работу

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

Как говорится, во-первых, это красиво. Во-вторых, повышает профессионализм команды в глазах заказчика, а из этого потом вырастет доверие. В-третьих, это психологически поддерживает менеджера. Даже самая захудалая презентация из четырёх слайдов снимет часть клиентских вопросов. Формула презентации примерно такая: приветствие и небольшой разговор ни о чем → показ презентации с параллельным рассказом о том, что сделали → показ макета, вёрстки или что там у нас.

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

Удовлетворённость клиента — вопрос жизни и смерти

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

Чем больше компетенций у команды, тем больше ценности в проекте

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

Когда клиент платит за проект, он платит в том числе и за опыт каждого человека в команде.

Идеала не будет

В заключение хочется сказать, что мир «идеального проекта» обязательно разрушится. Это просто надо принять. Как бы я ни хотел сделать всё по учебнику, по многим причинам так не получится. Что тут можно сделать? Смотреть на сложности в проектах более философски, пытаться делать так, как считаешь правильным, разговаривать и убеждать. В общем, пытаться делать хорошо, а плохо и само получится.