Моя команда создала бесполезный продукт — делюсь выводами, которые я из этого сделал

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

Привет! На связи команда TEAMLY. Мы создаем платформу для совместной работы и управления знаниями. В апреле у нас прошла конференция по управлению знаниями.

Одним из экспертов был Никита Зыликов — руководитель направления аналитики и методологии бизнес-процессов KAMAZ Digital и Natcar.
Он спроектировал бизнес-процессы нового терминала Шереметьево к чемпионату мира 2018 и разработал автоматизацию цифровой железнодорожной станции для РЖД.

На конференции он рассказал о своем опыте управления проектами — передаем слово Никите.

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

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

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

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

📌 Определите требования к проекту. В качестве отправной точки нужны хотя бы верхнеуровневые требования. Поймите что предстоит сделать и какие проблемы должен решить этот проект.

📌 Соберите команду. Лучше это делать поэтапно, чтобы не потратить бюджет впустую. В первую очередь нанимайте не разработчиков и тестировщиков, а тех, кто переведёт «язык бизнеса» на «язык технических специалистов» — то есть проджект-менеджера или аналитика. Пока они пишут требования, HR подберут сотрудников для реализации проекта.

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

Кроме того, к инфраструктуре относятся платформы, где можно управлять проектами, как TEAMLY. Они нужны чтобы ставить задачи, контролировать прогресс работы и вести документацию. Например, написать для сотрудников инструкции с правилами работы в программе.

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

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

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

📌 Определите роли. Бывает, что сотрудники совмещают обязанности. Иногда аналитики выполняют работу проджект-менеджера или даже владельца продукта. Если никто об этом не знает, то такие ситуации могут закончиться неразберихой, дублированием функций и конфликтами. Чтобы команда не сталкивалась лбами, расскажите на берегу кто какие задачи выполняет и за что несет ответственность.

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

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

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

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

Документация помогает прийти на встречу подготовленными. Кроме того, всего за час человек забывает 60% информации. Если не записывать итоги собрания, команда будет слабо понимать что нужно сделать.

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

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

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

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

📌 Показывайте процесс работы. Слова о том, что все идет по плану, звучат неубедительно, если заказчик не видит результат. Демонстрируйте даже небольшие наработки: написали требования, исправили ошибки. Так заказчик будет понимать, что проект не стоит на месте и про него не забыли.

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

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

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

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

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

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

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

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

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

Мы передали требования в отдел закупок и в результате торгов получили пять предложений:

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

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

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

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

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