Читать книгу Новая эра в IT - Эмиль Ахундов - Страница 3

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

По образованию я авиационный инженер. С детства увлекался техникой, мне всегда было интересно устройство гаджетов, автомобилей, самолетов. Поэтому закономерным выбором стал Московский Авиационный Институт, в котором ребят учат строить, создавать и поднимать в воздух многотонные машины. Закончив институт с отличием в 2015 году, к сожалению или к счастью, я не долго проработал в профессии. Для себя я понял, что есть более интересное занятие – написание программ, составление новых программных продуктов. Не имея в этом никакого опыта, прошел путь от рядового разработчика до управленца целой команды разработки. И уже тогда понял, что на одном техническом скиле сделать по-настоящему сложный проект невозможно. Программист в одиночку может осилить небольшой проект, но когда идет речь о федеральном проекте, на первый план выходит команда. О таких компетенциях и секретах создания качественных ИТ-продуктов я сегодня и расскажу. А пока вернемся к краткой истории моего пути.

В 2018 году мы с партнером увидели зарождающийся тренд на чат-ботов и тогда решили организовать агентство по созданию чат-ботов. Чат-боты – это те самые программы в мессенджерах, которые помогают людям быстрее решать свои задачи, а компаниям автоматизировать свои процессы. Более подробно о нашей компании можно почитать в нашем корпоративном блоге и в моем блоге на VC.

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

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

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

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

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

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

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

Что под этим подразумевается?

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

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

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

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

Следующий важный момент немного спорный: нужно ли давать клиенту возможность управлять процессом разработки? Я придерживаюсь мнения, что клиенту нужно показывать промежуточные результаты, но это должно быть как бы «за стеклом». Это значит, что вы собираете продукт, клиент видит, но не управляет. Впускать клиента в процесс чревато. Клиент по незнанию может давать такие корректировки, которые нарушают ваш технологический процесс. Тут нужно уловить тонкий баланс между демонстрацией, открытостью и приверженностью своим принципам, которыми вы руководствуетесь. У вас должна быть методология, фреймворк, принципы и технологии создания IT-продуктов.

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

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

В таких сервисных историях разработка идет итеративно. На первом этапе сделан один объем работ. Переходя на второй этап, при наличии бэклога, вы уже имеете список задач, которые нужно развивать с клиентом, чтобы внедрить в продукт. Наличие бэклог фиксации – записки на полях в журнале проекта. олжны быть какие-то «бортовые записи». Журнал проекта не должен быть пустым.

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

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

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

Завершить хотелось бы тем, что важен контроль обратной связи от клиента. Мы к этому также пришли не сразу. Начать советую с простого NPS-опроса. Это опрос, позволяющий в простом формате получить обратную связь через 10—15 вопросов: ак сделан продукт, что понравилось, что не понравилось. Такой опросник для нас стал целым океаном инсайтов. Клиенты готовы делиться обратной связью, они помогут вам понять, в какую сторону двигаться, чтобы развиваться.

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

Стоит также отметить методологию кастдевов – глубинных интервью с клиентом. Где с клиентом по факту завершения проекта (а иногда и на старте), выясняется, как все прошло, какие были цели у проекта. Мы часто практикуем в конце проекта так называемую рефлексию вместе с клиентом. Именно он расскажет, каким вам надо стать.