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

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

На связи Ахмад Боков, основатель чат-бот агентства BotCreators.ru и диджитал-продакшна «Искусство Автоматизации».

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

Закончив институт, к сожалению или к счастью, я не долго проработал в профессии. Для себя я понял, что есть более интересное занятие — написание программ, составление новых программных продуктов.

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

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

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

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

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

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

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

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

В этом есть много плюсов. Осведомленность снимает нервозность, страхи, тревоги клиента о проекте и конечной цели, к которой вы вместе идёте.

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

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

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

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

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

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

Ещё момент, которому нужно научиться, — управлять ожиданиями клиента. Это значит слышать клиента, фиксировать моменты, которые он подсвечивает. Как это делаем мы: всё, что обсуждается на проекте, не проходит мимо нас. Каждая фраза, всё, что прозвучало на обсуждении, заносится в бэклог. В таких сервисных историях разработка идёт итеративно.

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

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

Мы должны давать подготовленный продукт, проверенный и протестированный. Клиент не проверяет качество, а получает продукт уже в рабочем состоянии.

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

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

Начать советую с простого NPS-опроса. Это опрос, позволяющий в простом формате получить обратную связь через 10—15 вопросов: как сделан проект, что понравилось, что не понравилось.

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

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

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

Опубликовал свои размышления из книги «Новая эра в IT». Ссылки на скачивание есть в нашем блоге BotCreators.ru