Удовлетворенность клиента продуктом (CS, customer satisfaction) - зачем и как его измерять?
Один из моих клиентов вчера звонит мне с вопросом: с какой периодичностью и какие митинги проводить с моей продуктовой командой? А у него бизнес около-проектный. Продают мини-электростанции под ключ. Каждый заказчик - это проект, но в каждом из них уже есть генерирующая установка как основа. Поэтому не проектный, а около-проектный. Платформа со сценариями. Длительность каждого проекта - в районе 6-12 мес.
Проектный руководитель (ПМ) у него есть, всё ок. Но общую картинку по проекту собственник, говорит, не видит. Может только поверить на слово ПМу. Хочу, говорит, большей прозрачности. Ты ж умеешь, сделай мне кайтен, как в (другая компания, где я ему помог кайтеном). Но там совсем другая песня. Там бизнес продуктовый, и много продуктовой разработки. А тут разработка начнется позже, пока просто заказать, собрать, проверить, запустить, сдать.
Более того, ПМ-а всё устраивает (ms project + teams). Глядя в гантт и перт по каждому проекту, собственник понимает, что ничего не понимает. А они (команда) там живут, поэтому всё понимают. А надо ли понимать? А если не понимать, то какие элементы из всего множества элементов надо контролировать?
Спрашиваю про COGS - бюджет проекта у него уже под контролем. А вот CS он не контролирует, и даже не знал что это такое и зачем его мерить. Рассказываю. Продукт начинается там, где уже привлекли и продали: клиент заплатил за что-то и у него есть какие-то ожидания. Customer Satisfaction - это степень попадания в ожидания клиента.
Если попали на 100%, клиент будет доволен. Если попали больше чем на 100%, у клиента случается wow-эффект, и он скорее всего придет ещё раз и/или будет рассказывать о продукте своим друзьям, знакомым, коллегам. Если попали меньше чем на 100%, клиент также скорее всего будет рассказывать другим о продукте, но уже негатив.
Поэтому важно вспомнить, что же именно пообещали клиенту при продаже? Что именно он купил? И самое важное - почему он это купил? Что там у него за ситуация, из-за которой он раскошелился? Из офиц ТЗ это совсем неочевидно.
Из ответов на эти вопросы получается список ожиданий клиента, в который надо попасть своим продуктом. Каждое ожидание можно определить, например, по 3х или 5ти бальной шкале, и делать это в двух местах: перед отгрузкой продукта (услуги) аналитически, и после отгрузки продукта эмпирически - интервью с клиентом. Это называется "контроль ценности". Понимая ситуацию клиента и его реальные цели мы можем заранее придумать, что сделать для него сверх обещаний, чтобы вызвать wow-эффект и также включить это в контроль ценности.
В случае моего клиента, по проекту получились вот такие критерии:
- запуск к марту 2022, т.к. начинается очередной сезон и существующих мощностей перестанет хватать
- бесперебойные мощности (на что есть SLA)
- конкретный уровень потребления топлива
- конкретная мощность на выходе
- должно работать параллельно с уже существующим генерирующим оборудованием (расширять, а не заменять мощности)
- в момент запуска допускается пропадание питания не более чем на одни сутки, потому что каждый день питания на солярке стоят заказчику X млн руб
Собственник понял, что дело не в кайтене. Какая разница, какой инструмент используется, если теперь он знает, что действительно важно, что надо контролировать, а всё остальное можно оставить ПМу.
Один из моих клиентов вчера звонит мне с вопросом: с какой периодичностью и какие митинги проводить с моей продуктовой командой? А у него бизнес около-проектный. Продают мини-электростанции под ключ. Каждый заказчик - это проект, но в каждом из них уже есть генерирующая установка как основа. Поэтому не проектный, а около-проектный. Платформа со сценариями. Длительность каждого проекта - в районе 6-12 мес.
Проектный руководитель (ПМ) у него есть, всё ок. Но общую картинку по проекту собственник, говорит, не видит. Может только поверить на слово ПМу. Хочу, говорит, большей прозрачности. Ты ж умеешь, сделай мне кайтен, как в (другая компания, где я ему помог кайтеном). Но там совсем другая песня. Там бизнес продуктовый, и много продуктовой разработки. А тут разработка начнется позже, пока просто заказать, собрать, проверить, запустить, сдать.
Более того, ПМ-а всё устраивает (ms project + teams). Глядя в гантт и перт по каждому проекту, собственник понимает, что ничего не понимает. А они (команда) там живут, поэтому всё понимают. А надо ли понимать? А если не понимать, то какие элементы из всего множества элементов надо контролировать?
Спрашиваю про COGS - бюджет проекта у него уже под контролем. А вот CS он не контролирует, и даже не знал что это такое и зачем его мерить. Рассказываю. Продукт начинается там, где уже привлекли и продали: клиент заплатил за что-то и у него есть какие-то ожидания. Customer Satisfaction - это степень попадания в ожидания клиента.
Если попали на 100%, клиент будет доволен. Если попали больше чем на 100%, у клиента случается wow-эффект, и он скорее всего придет ещё раз и/или будет рассказывать о продукте своим друзьям, знакомым, коллегам. Если попали меньше чем на 100%, клиент также скорее всего будет рассказывать другим о продукте, но уже негатив.
Поэтому важно вспомнить, что же именно пообещали клиенту при продаже? Что именно он купил? И самое важное - почему он это купил? Что там у него за ситуация, из-за которой он раскошелился? Из офиц ТЗ это совсем неочевидно.
Из ответов на эти вопросы получается список ожиданий клиента, в который надо попасть своим продуктом. Каждое ожидание можно определить, например, по 3х или 5ти бальной шкале, и делать это в двух местах: перед отгрузкой продукта (услуги) аналитически, и после отгрузки продукта эмпирически - интервью с клиентом. Это называется "контроль ценности". Понимая ситуацию клиента и его реальные цели мы можем заранее придумать, что сделать для него сверх обещаний, чтобы вызвать wow-эффект и также включить это в контроль ценности.
В случае моего клиента, по проекту получились вот такие критерии:
- запуск к марту 2022, т.к. начинается очередной сезон и существующих мощностей перестанет хватать
- бесперебойные мощности (на что есть SLA)
- конкретный уровень потребления топлива
- конкретная мощность на выходе
- должно работать параллельно с уже существующим генерирующим оборудованием (расширять, а не заменять мощности)
- в момент запуска допускается пропадание питания не более чем на одни сутки, потому что каждый день питания на солярке стоят заказчику X млн руб
Собственник понял, что дело не в кайтене. Какая разница, какой инструмент используется, если теперь он знает, что действительно важно, что надо контролировать, а всё остальное можно оставить ПМу.
Неважно какой у вас сейчас T2M. Scrum сразу же радикально и бескомпромиссно снижает его до длинны одного спринта.
Владелец продукта не обязан отгружать в операционку инкремент продукта после обзора спринта. Но если он захочет - он может это сделать. Это решение целиком и полностью лежит в коммерческой области, а не в технической.
Вот почему так важно иметь на обзоре действительно до конца сделанную работу, готовый инкремент. Что значит "готовый" - написано в Definition of Done. Всё, что используется на обзоре для сбора обратной связи должно быть действительно сделано, без всяких "почти", "частично", "только дизайн" и т.д.
Работающий продукт - это главный измеритель прогресса в гибкой организации. Если вы, как Scrum-мастер, видите препятствия радикального сокращения T2M до длинны одного спринта, то у вас два выхода:
1. Сдаться и подкрутить Scrum под организацию - мы имеем на обзоре неготовый или частично готовый функционал, и для нашей организации это нормально. T2M становится больше длины одного спринта, и ценность Scrum-фреймворка падает до нуля. Рассмотрите переход на kanban-метод. Гибкость тоже будет достигнута, но не радикальным, революционным и быстрым путем, а более мягко, эволюционно и медленно.
2. Признать наличие проблемы и заняться её решением. Что мешает команде делать Done-инкремент? Если ограничение внутри - надеваем шапку коуча и на ретроспективе помогаем команде найти ограничение и решение. Если ограничение вовне - надеваем шапку менеджера и идем менять организацию.
Владелец продукта не обязан отгружать в операционку инкремент продукта после обзора спринта. Но если он захочет - он может это сделать. Это решение целиком и полностью лежит в коммерческой области, а не в технической.
Вот почему так важно иметь на обзоре действительно до конца сделанную работу, готовый инкремент. Что значит "готовый" - написано в Definition of Done. Всё, что используется на обзоре для сбора обратной связи должно быть действительно сделано, без всяких "почти", "частично", "только дизайн" и т.д.
Работающий продукт - это главный измеритель прогресса в гибкой организации. Если вы, как Scrum-мастер, видите препятствия радикального сокращения T2M до длинны одного спринта, то у вас два выхода:
1. Сдаться и подкрутить Scrum под организацию - мы имеем на обзоре неготовый или частично готовый функционал, и для нашей организации это нормально. T2M становится больше длины одного спринта, и ценность Scrum-фреймворка падает до нуля. Рассмотрите переход на kanban-метод. Гибкость тоже будет достигнута, но не радикальным, революционным и быстрым путем, а более мягко, эволюционно и медленно.
2. Признать наличие проблемы и заняться её решением. Что мешает команде делать Done-инкремент? Если ограничение внутри - надеваем шапку коуча и на ретроспективе помогаем команде найти ограничение и решение. Если ограничение вовне - надеваем шапку менеджера и идем менять организацию.
Что нас мотивирует в работе кроме денег?
Конечно, всем нужны деньги. И все хотят быть богаче, иметь больше денег. Это естественно для человека - хотеть большего, чем у него есть сейчас. Но деньги - это базовая потребность, безопасность. Если человек может спокойно сосредоточиться на работе, не думая о том, где взять денег, значит доход на данном этапе его устраивает.
Более того, деньги сами по себе не увеличивают радость и счастье. Они увеличивают то, что у человека УЖЕ есть. Если человек в депрессии из-за семейных проблем, либо он страдает из-за плохих условий труда, то деньги в конечном итоге усилят депрессию и страдания. Если человек наоборот, удовлетворен своей семьей, своей работой, испытывает радость от достижений, то деньги усилят удовлетворение и радость.
Поэтому денежная мотивация не должна использоваться в первую очередь. Это скорее дополнение к другим, нефинансовым мотиваторам:
1. Автономность
2. Мастерство
3. Смысл
Автономность - это возможность применить свой человеческий творческий потенциал в решении задачи. Чтобы понять, нужно что-то улучшать или нет - посмотрите как сотрудник получает задачи. Чем больше там указаний на тему КАК выполнять работу вместе с описанием ЧТО нужно получить в итоге (какой результат), тем ниже автономность, и соответственно ниже мотивация трудиться. В идеале, сотрудник получает только описание требуемого результата и понятные границы, а конкретный способ выполнения работ он выбирает полностью самостоятельно и независимо.
Мастерство - это ощущение личного профессионального роста в процессе выполнения работы. Если человек не чувствует, не понимает, как он повысил какое-то своё мастерство, стал лучше, то мотивация будет ниже. Чтобы понять, как стимулировать этот фактор мотивации, помогите вашей команде (вашему коллективу) создать матрицу компетенций и отметить там необходимость и желание людей обучаться. В идеале, коллеги по цеху, обладающие нужной квалификацией, помогут, обучат, возьмут на себя наставничество. Но даже если нет, вы поймете, кому и какие курсы покупать.
Смысл - это ясное понимание, как моя работа помогает другим людям. Начните с компании. Видит ли каждый из сотрудников, как его функция и его задачи, которые он делает каждый день, помогают компании достичь цели? Видит ли он своё место в общей функции достижения цели? План регулярно актуализируется или уже давно устарел и не обновляется? В идеале, есть смартованая тактическая цель у всей организации, план всегд актуален (используется гибкий формат) и каждый видит свою работу в нём.
Подробнее можно почитать в книге Дэниэл Пинк "Драйв. Что на самом деле нас мотивирует"
Конечно, всем нужны деньги. И все хотят быть богаче, иметь больше денег. Это естественно для человека - хотеть большего, чем у него есть сейчас. Но деньги - это базовая потребность, безопасность. Если человек может спокойно сосредоточиться на работе, не думая о том, где взять денег, значит доход на данном этапе его устраивает.
Более того, деньги сами по себе не увеличивают радость и счастье. Они увеличивают то, что у человека УЖЕ есть. Если человек в депрессии из-за семейных проблем, либо он страдает из-за плохих условий труда, то деньги в конечном итоге усилят депрессию и страдания. Если человек наоборот, удовлетворен своей семьей, своей работой, испытывает радость от достижений, то деньги усилят удовлетворение и радость.
Поэтому денежная мотивация не должна использоваться в первую очередь. Это скорее дополнение к другим, нефинансовым мотиваторам:
1. Автономность
2. Мастерство
3. Смысл
Автономность - это возможность применить свой человеческий творческий потенциал в решении задачи. Чтобы понять, нужно что-то улучшать или нет - посмотрите как сотрудник получает задачи. Чем больше там указаний на тему КАК выполнять работу вместе с описанием ЧТО нужно получить в итоге (какой результат), тем ниже автономность, и соответственно ниже мотивация трудиться. В идеале, сотрудник получает только описание требуемого результата и понятные границы, а конкретный способ выполнения работ он выбирает полностью самостоятельно и независимо.
Мастерство - это ощущение личного профессионального роста в процессе выполнения работы. Если человек не чувствует, не понимает, как он повысил какое-то своё мастерство, стал лучше, то мотивация будет ниже. Чтобы понять, как стимулировать этот фактор мотивации, помогите вашей команде (вашему коллективу) создать матрицу компетенций и отметить там необходимость и желание людей обучаться. В идеале, коллеги по цеху, обладающие нужной квалификацией, помогут, обучат, возьмут на себя наставничество. Но даже если нет, вы поймете, кому и какие курсы покупать.
Смысл - это ясное понимание, как моя работа помогает другим людям. Начните с компании. Видит ли каждый из сотрудников, как его функция и его задачи, которые он делает каждый день, помогают компании достичь цели? Видит ли он своё место в общей функции достижения цели? План регулярно актуализируется или уже давно устарел и не обновляется? В идеале, есть смартованая тактическая цель у всей организации, план всегд актуален (используется гибкий формат) и каждый видит свою работу в нём.
Подробнее можно почитать в книге Дэниэл Пинк "Драйв. Что на самом деле нас мотивирует"
Чтобы наконец-то начать делать то, что он так долго откладывает на потом из-за высокой степени неопределенности и сложности задачи. Это может быть поиск новых каналов, освоение новых возможностей развития бизнеса, выход на зарубежные рынки, и даже переход из найма в своё дело.
Не так давно у меня на диагностике был предприниматель из сферы dark store. У него есть небольшая АКБ (активная клиентская база), небольшой оборот и он, естественно, хочет расти. Целых два года он занимается этим проектом: постоянно ищет какие-то возможности, обдумывает разные варианты. Он даже устроился на пару месяцев на работу к крупным игрокам на рынке, чтобы посмотреть, как всё устроено изнутри.
У предпринимателя есть крутое ЦП: в номенклатуре есть уникальный продукт с высокой потенциальной ценностью, который больше на рынке нигде не купить. Но он никак не может приступить к активным действиям. В каждой идее есть так много неопределенности, что это парализует его, заставляя делать не то, что надо, а то что понятно - продолжать развивать свою АКБ, проводить с ней вовлекающие мероприятия, расширять ассортимент по обратной связи, и т.д.
На диагностике выяснилось, что бизнес заблокирован из-за ложной идеи, что цена продукта должна строиться на себестоимости. Из-за чего даже у его активных клиентов порой возникают сомнения в качестве продукта, не говоря уже о новых потенциальных клиентах. Мы эту идею успешно развенчали и стали рассматривать имеющиеся варианты - мелкий опт, свои он-лайн каналы. Мелкий опт - это сертификация, в ходе которой от его ЦП ничего не останется. Он-лайн каналы выглядят лучше, но нужна красивая упаковка, SMM-щики - вобщем команда. А на команду денег сейчас нет.
Несколько вопросов, и оказалось, что ограничение не в том, что нет команды и денег, а в том что предприниматель не знает как упаковать своё ЦП и кто его ЦА? Буквально за 10 минут он сварганил ЦП и придумал эксперимент по проверке: прикинул где взять новых потенциальных клиентов и сколько он сможет сделать тестовых пробных продаж за неделю. Крайний вопрос прозвучал риторически: "почему я сам до сих пор не попробовал такой эксперимент?"
В этом ценность трекера. Предпринимателю нужен спаринг-партнер, который обладает достаточной продуктовой экспертизой, чтобы найти точку приложения усилий с максимальным бизнес-результатом в текущей связке время-место-обстоятельства.
Не так давно у меня на диагностике был предприниматель из сферы dark store. У него есть небольшая АКБ (активная клиентская база), небольшой оборот и он, естественно, хочет расти. Целых два года он занимается этим проектом: постоянно ищет какие-то возможности, обдумывает разные варианты. Он даже устроился на пару месяцев на работу к крупным игрокам на рынке, чтобы посмотреть, как всё устроено изнутри.
У предпринимателя есть крутое ЦП: в номенклатуре есть уникальный продукт с высокой потенциальной ценностью, который больше на рынке нигде не купить. Но он никак не может приступить к активным действиям. В каждой идее есть так много неопределенности, что это парализует его, заставляя делать не то, что надо, а то что понятно - продолжать развивать свою АКБ, проводить с ней вовлекающие мероприятия, расширять ассортимент по обратной связи, и т.д.
На диагностике выяснилось, что бизнес заблокирован из-за ложной идеи, что цена продукта должна строиться на себестоимости. Из-за чего даже у его активных клиентов порой возникают сомнения в качестве продукта, не говоря уже о новых потенциальных клиентах. Мы эту идею успешно развенчали и стали рассматривать имеющиеся варианты - мелкий опт, свои он-лайн каналы. Мелкий опт - это сертификация, в ходе которой от его ЦП ничего не останется. Он-лайн каналы выглядят лучше, но нужна красивая упаковка, SMM-щики - вобщем команда. А на команду денег сейчас нет.
Несколько вопросов, и оказалось, что ограничение не в том, что нет команды и денег, а в том что предприниматель не знает как упаковать своё ЦП и кто его ЦА? Буквально за 10 минут он сварганил ЦП и придумал эксперимент по проверке: прикинул где взять новых потенциальных клиентов и сколько он сможет сделать тестовых пробных продаж за неделю. Крайний вопрос прозвучал риторически: "почему я сам до сих пор не попробовал такой эксперимент?"
В этом ценность трекера. Предпринимателю нужен спаринг-партнер, который обладает достаточной продуктовой экспертизой, чтобы найти точку приложения усилий с максимальным бизнес-результатом в текущей связке время-место-обстоятельства.
На консультацию пришла предприниматель. Вместе с партнерами она отдала в разработку 10 млн. руб. И за 1.5 года ей выдали полный дефектов продукт, который даже показать стыдно, не говоря уже о продажах. Разработчики проверенные, но они пытались сделать сразу всё и как надо. В результате у них сейчас разборки. Меня она попросила помочь найти разработчика, который с нуля сделает демку для инвестора, чтобы поднять раунд и добежать до продаж.
Пауза...
20% инвестиций в разработку приносят 80% бизнес-эффекта. Как надо писать ТЗ, чтобы первая версия продукта принесла эти самые 80% бизнес-эффекта за 20% инвестиций?
Проблема в том, что заказчик не знает, какие 20% функций продукта дадут 80% бизнес-эффекта. Это станет видно только когда продукт будет разработан, пользователи начнут его использовать и заказчик сможет сравнить фактический бизнес-эффект с ожидаемым. Имеем следующую цепочку зависимостей: фукнционал продукта -> изменение поведения пользователей -> бизнес-эффект. Обе зависимости представляют из себя прыжок веры заказчика - гипотезу, которую он проверяет с помощью разработки.
Здесь и кроется ответ на вопрос про ТЗ:
- с какими минимальными затратами по времени и деньгам можно убедиться, что изменение поведения пользователей даст бизнес-эффект? С разработкой или без это называется MVP (minimum viable product).
- какой минимальный набор функциональности продукта нужен, чтобы получить 80% бизнес-эффекта? Это первый релиз.
Есть специальный гибкий формат описания релизного плана - storymap. Чтобы поработать с ним, мы сначала описываем текущий опыт пользователей и желаемые изменения в нем. Это позволяет отсечь лишний функционал и сосредоточиться на главном.
Возвращаемся к нашему предпринимателю...
После часовой консультации предприниматель получила ТЗ и ушла искать разработчика. А через неделю я выяснил, что она выделила немного времени и собирает демку сама. Требуемый функционал оказался настолько маленьким, что она отказалась от услуг разработчиков на данном этапе.
Пауза...
20% инвестиций в разработку приносят 80% бизнес-эффекта. Как надо писать ТЗ, чтобы первая версия продукта принесла эти самые 80% бизнес-эффекта за 20% инвестиций?
Проблема в том, что заказчик не знает, какие 20% функций продукта дадут 80% бизнес-эффекта. Это станет видно только когда продукт будет разработан, пользователи начнут его использовать и заказчик сможет сравнить фактический бизнес-эффект с ожидаемым. Имеем следующую цепочку зависимостей: фукнционал продукта -> изменение поведения пользователей -> бизнес-эффект. Обе зависимости представляют из себя прыжок веры заказчика - гипотезу, которую он проверяет с помощью разработки.
Здесь и кроется ответ на вопрос про ТЗ:
- с какими минимальными затратами по времени и деньгам можно убедиться, что изменение поведения пользователей даст бизнес-эффект? С разработкой или без это называется MVP (minimum viable product).
- какой минимальный набор функциональности продукта нужен, чтобы получить 80% бизнес-эффекта? Это первый релиз.
Есть специальный гибкий формат описания релизного плана - storymap. Чтобы поработать с ним, мы сначала описываем текущий опыт пользователей и желаемые изменения в нем. Это позволяет отсечь лишний функционал и сосредоточиться на главном.
Возвращаемся к нашему предпринимателю...
После часовой консультации предприниматель получила ТЗ и ушла искать разработчика. А через неделю я выяснил, что она выделила немного времени и собирает демку сама. Требуемый функционал оказался настолько маленьким, что она отказалась от услуг разработчиков на данном этапе.
Меня часто спрашивают, сколько стоит разработать мобильное/web приложение?
IT-разработка - это проект. Если заказчик копирует уже существующее приложение, то скорее всего он напишет ТЗ, отдаст подрядчикам на оценку, соберет "котировки" и выберет того, кто выглядит лучше всех по соотношению цена/репутация. Затем со стороны выбранного подрядчика последует вполне стандартное проектное управление, цель которого - выдать результат в срок, с оговоренным заранее бюджетом и без дефектов. Тут тоже есть свои проблемы, но их достаточно легко решить с помощью kanban-метода.
Если же заказчик хочет принципиально новое приложение, аналогов которому на рынке нет, то риск выхода за рамки бюджета и сроков не получится снизить таким предварительным анализом. Как бы подробно мы не описывали требуемый функционал приложения, реальность внесет свои (порой радикальные) коррективы. Чаще всего заказчик этого не понимает, и идет в проект по вышеописанному сценарию, стараясь переложить все риски на подрядчика. На выходе, предсказуемо, получает полный дефектов результат, который как чемодан без ручки - и практической пользы не имеет, и бросить его жалко.
Допустим что заказчик это всё понимает. Что ему делать, чтобы контролировать риски?
Во-первых, понять источник риска - пользовательский опыт. Ключевая гипотеза заказчика в том, что он получит бизнес-эффект, когда пользователи поменяют своё поведение, когда получат новое приложение. Если пользователи не поменяют своё поведение, бизнес-эффекта не будет.
Во-вторых, выделить наиболее рискованные элементы пользовательского опыта и запланировать их проверку вместе подрядчиком через концепцию MVP (см. предыдущий пост в ленте). Получится цепочка экспериментов с пользователями, которые надо сделать заказчику с помощью подрядчика.
В-третьих, написать ТЗ в таком формате, чтобы его можно было легко менять в процессе проверки пользовательского опыта. Например, формат бэклога продукта с оценкой в функциональных единицах (story point). Оценку бэклога делаем вместе с подрядчиком, добавляем 10% на непредвиденные обстоятельства и получаем бюджет. После каждого эксперимента обновляем бэклог продукта - добавляем, удаляем, меняем или переставляем элементы - и делаем перерасчет. Таким образом, заказчик сможет контролировать риск выхода за рамки своего бюджета и сроков.
IT-разработка - это проект. Если заказчик копирует уже существующее приложение, то скорее всего он напишет ТЗ, отдаст подрядчикам на оценку, соберет "котировки" и выберет того, кто выглядит лучше всех по соотношению цена/репутация. Затем со стороны выбранного подрядчика последует вполне стандартное проектное управление, цель которого - выдать результат в срок, с оговоренным заранее бюджетом и без дефектов. Тут тоже есть свои проблемы, но их достаточно легко решить с помощью kanban-метода.
Если же заказчик хочет принципиально новое приложение, аналогов которому на рынке нет, то риск выхода за рамки бюджета и сроков не получится снизить таким предварительным анализом. Как бы подробно мы не описывали требуемый функционал приложения, реальность внесет свои (порой радикальные) коррективы. Чаще всего заказчик этого не понимает, и идет в проект по вышеописанному сценарию, стараясь переложить все риски на подрядчика. На выходе, предсказуемо, получает полный дефектов результат, который как чемодан без ручки - и практической пользы не имеет, и бросить его жалко.
Допустим что заказчик это всё понимает. Что ему делать, чтобы контролировать риски?
Во-первых, понять источник риска - пользовательский опыт. Ключевая гипотеза заказчика в том, что он получит бизнес-эффект, когда пользователи поменяют своё поведение, когда получат новое приложение. Если пользователи не поменяют своё поведение, бизнес-эффекта не будет.
Во-вторых, выделить наиболее рискованные элементы пользовательского опыта и запланировать их проверку вместе подрядчиком через концепцию MVP (см. предыдущий пост в ленте). Получится цепочка экспериментов с пользователями, которые надо сделать заказчику с помощью подрядчика.
В-третьих, написать ТЗ в таком формате, чтобы его можно было легко менять в процессе проверки пользовательского опыта. Например, формат бэклога продукта с оценкой в функциональных единицах (story point). Оценку бэклога делаем вместе с подрядчиком, добавляем 10% на непредвиденные обстоятельства и получаем бюджет. После каждого эксперимента обновляем бэклог продукта - добавляем, удаляем, меняем или переставляем элементы - и делаем перерасчет. Таким образом, заказчик сможет контролировать риск выхода за рамки своего бюджета и сроков.
Капитанский ответ - потому что таков рынок труда в IT. Минцифры в феврале 2021 года сообщили о нехватке от полумиллиона до миллиона IT-специалистов. Но это плохой ответ. Потому что он не дает пищи для размышлений на тему "что делать?". Хороший ответ в том, что затраты на них - это капитальные, а не операционные затраты. Нет, я не призываю вас выгонять их из штата в договорные отношения, где они будут подписываться под возврат инвестиций. Пусть бухучет останется как есть. Вопрос в другом - в управлении.
Кто среди ваших сотрудников системно работает на то, чтобы повысить выручку и/или снизить издержки? Весьма вероятно, что это только вы сами. Остальных вы нанимали для того, чтобы было кому делать операционные задачи - крутить бизнес. Даже руководители вплоть до ТОП-уровня. Их можно привлечь к инвестиционной деятельности, но это не будет их основной работой. Однако, разработчики (и в целом IT-шники), это пожалуй единственные люди, которые нанимались в первую очередь для того, чтобы повышать выручку и/или снижать издержки и/или увеличивать капитализацию бизнеса (далее по тексту кратко - бизнес-результат). Операционные задачи они иногда выполняют. Например, оказывают техподдержку. Но для них это явно второстепенная роль.
Почему же тогда у владельца часто возникают сомнения в том, что разработчики вообще выполняют свою основную роль? Стоимость у них, как у чугунного моста, а эффект никакой или низкий. И уволить нельзя. Даже если новых разработчиков аналогичной квалификации удастся найти (вспоминаем про рынок труда в IT), то есть риск, что они не смогут разобраться в коде и будут всё переписывать с нуля. Какая-то запутанная ситуация.
Один из предпринимателей у меня на контроле ценности после диагностики сказала: "У меня было ощущение запутанного клубка, внутри которого я нахожусь. И любое моё движение запутывает его ещё сильнее. Мне нужно было найти конец, чтобы начать его распутывать". Давайте разберемся, где конец у этого клубка?
Может быть надо тратить ещё больше, чтобы с гарантией нанимать лучших? Нет, не угадали. Можно встретить зарплату в 700 тыс руб на руки (!) у CTO небольшой команды, который не делает для бизнеса ровным счетом ничего. И уволить нельзя - заменить некем. С другой стороны у меня есть кейс, когда кросс-функциональная команда из вновь нанятых джунов за 3 месяца достаточно качественно запилила то, что за два года не могли сделать матерые мидлы с сеньорами.
Может быть внедрить один из модных Agile-фреймворков? Спринты, регулярные обзоры? Командная работа? Теплее. Но слишком абстрактно. Рискуете выкинуть много денег впустую. Дело не в том, КАК работают разработчики. И даже не в том, сколько они получают. Хотя конечно надо платить достойную зарплату. Главное - как вы воспринимаете результат их труда? За что вы им платите зарплату?
Один из моих знакомых предпринимателей, когда впервые пошел в IT, искренне считал, что если за месяц не написано ни одной строчки кода, то время потеряно зря. Он хотел платить за код. И есть такие разработчики, которые ненавидят всякие Agile-фреймворки. Они просто хотят писать код, и хотят чтобы им за это платили. Наберите в поисковике zed a shaw manifesto, и вы найдете их манифест. Позвольте пару цитат оттуда в перводе на русский. С цензурой, естественно.
"Мы - сообщество ублюдочных программистов, которых годами унижали разными методологиями разработки программного обеспечения. Мы устали от XP, Scrum, Kanban и всего остального, что встает на пути программирования, (цензура). Мы устали выслушивать, что мы асоциальные идиоты, которыми приходится манипулировать, чтобы мы ишачили парным программированием, как в цепной банде (chain gang) без всякой передышки на творчество, потому что ни один из 10 менеджеров в проекте не может ... программировать, (цензура)! Мы должны уничтожить эти методологии, которые встают на пути ... программирования, (цензура)!"
Кто среди ваших сотрудников системно работает на то, чтобы повысить выручку и/или снизить издержки? Весьма вероятно, что это только вы сами. Остальных вы нанимали для того, чтобы было кому делать операционные задачи - крутить бизнес. Даже руководители вплоть до ТОП-уровня. Их можно привлечь к инвестиционной деятельности, но это не будет их основной работой. Однако, разработчики (и в целом IT-шники), это пожалуй единственные люди, которые нанимались в первую очередь для того, чтобы повышать выручку и/или снижать издержки и/или увеличивать капитализацию бизнеса (далее по тексту кратко - бизнес-результат). Операционные задачи они иногда выполняют. Например, оказывают техподдержку. Но для них это явно второстепенная роль.
Почему же тогда у владельца часто возникают сомнения в том, что разработчики вообще выполняют свою основную роль? Стоимость у них, как у чугунного моста, а эффект никакой или низкий. И уволить нельзя. Даже если новых разработчиков аналогичной квалификации удастся найти (вспоминаем про рынок труда в IT), то есть риск, что они не смогут разобраться в коде и будут всё переписывать с нуля. Какая-то запутанная ситуация.
Один из предпринимателей у меня на контроле ценности после диагностики сказала: "У меня было ощущение запутанного клубка, внутри которого я нахожусь. И любое моё движение запутывает его ещё сильнее. Мне нужно было найти конец, чтобы начать его распутывать". Давайте разберемся, где конец у этого клубка?
Может быть надо тратить ещё больше, чтобы с гарантией нанимать лучших? Нет, не угадали. Можно встретить зарплату в 700 тыс руб на руки (!) у CTO небольшой команды, который не делает для бизнеса ровным счетом ничего. И уволить нельзя - заменить некем. С другой стороны у меня есть кейс, когда кросс-функциональная команда из вновь нанятых джунов за 3 месяца достаточно качественно запилила то, что за два года не могли сделать матерые мидлы с сеньорами.
Может быть внедрить один из модных Agile-фреймворков? Спринты, регулярные обзоры? Командная работа? Теплее. Но слишком абстрактно. Рискуете выкинуть много денег впустую. Дело не в том, КАК работают разработчики. И даже не в том, сколько они получают. Хотя конечно надо платить достойную зарплату. Главное - как вы воспринимаете результат их труда? За что вы им платите зарплату?
Один из моих знакомых предпринимателей, когда впервые пошел в IT, искренне считал, что если за месяц не написано ни одной строчки кода, то время потеряно зря. Он хотел платить за код. И есть такие разработчики, которые ненавидят всякие Agile-фреймворки. Они просто хотят писать код, и хотят чтобы им за это платили. Наберите в поисковике zed a shaw manifesto, и вы найдете их манифест. Позвольте пару цитат оттуда в перводе на русский. С цензурой, естественно.
"Мы - сообщество ублюдочных программистов, которых годами унижали разными методологиями разработки программного обеспечения. Мы устали от XP, Scrum, Kanban и всего остального, что встает на пути программирования, (цензура). Мы устали выслушивать, что мы асоциальные идиоты, которыми приходится манипулировать, чтобы мы ишачили парным программированием, как в цепной банде (chain gang) без всякой передышки на творчество, потому что ни один из 10 менеджеров в проекте не может ... программировать, (цензура)! Мы должны уничтожить эти методологии, которые встают на пути ... программирования, (цензура)!"
Получается, что владельцы, которые хотят платить за код, находят программистов, которые хотят писать код. Они находят друг друга. И всё в порядке. До тех пор, пока не возникают вышеописанные проблемы с зависимостью бизнеса от конкретных разработчиков, низкой эффективностью затрат в разработку, чудовищными неоправданными зарплатами разработчиков, и т.д.
За что же надо платить разработчику, чтобы он работал на бизнес, а не наоборот? Правильный ответ - за изменения в операционном процессе бизнеса, которые ведут к бизнес-результату. Значит всё дело в том, как мы ставим задачи в разработку. Если мы говорим, что нам нужен функционал - то получим вышеописанные проблемы. Если мы приносим описание желаемых изменений в операционном процессе, то уже теплее, но эффективность всё ещё оставит желать лучшего. Идеально - приносить разработчикам причинно-следственную связь между желаемым бизнес-результатом и конкретными изменениями в операционном процессе, чтобы вместе с разработчиками придумать под это нужный функционал.
Но позвольте. Как же с ними общаться? Они же вообще нифига не понимают в бизнесе. А я нифига не понимаю в том, чего они делают и говорят. Как мы найдем общий язык? Антон, ты с дуба рухнул?
Есть такая проблема. Вы вместе с ними обладаете всем необходимым знанием, всеми необходимыми компетенциями. Вы всё понимаете в своём бизнесе. Они всё понимают в технологиях. Но проблема в том, что вы не можете разговаривать и договариваться. Поэтому вам нужен третий. Но не для того, чтобы стать между вами посредником. Так будет ещё хуже. А для того, чтобы помочь вам понять друг друга, найти общий язык, научиться вместе эффективно работать на бизнес-результат.
И это не трекер предпринимателей. Эти товарищи пошлют вас подальше с запросом помочь решить проблему в IT-разработке. Это не консультант по IT-разработке, потому что он непременно пойдет руководить вашими разработчиками. Это несколько IT-ролей в одном человеке:
- коуч: помогает дойти от бизнес-результата до конкретных требований в разработке, и от общих проблем в разработке до конкретных действий по их устранению
- фасилитатор: помогает найти общий язык с IT-шниками
- ментор: приносит провереный IT-менеджерский опыт
- тренер: вместе с вами работает на эффективность в разработке
И, ваша удача, что такие люди на рынке не только есть. Они даже имеют международно признанную сертификацию. И называется эта роль - Scrum-мастер. И его даже не обязательно звать в штат. Можно на время, проектно. А чтобы Scrum не стал карго-культом, как это чаще всего бывает, четко поставьте ему задачу. А именно - опишите желаемый бизнес-результат, на который он будет работать вместе с вами. И когда согласие будет достигнуто, то первое, что вы должны сделать: вдвоем сесть, и расписать ваши гипотезы причинно-следственных связей в операционке вашего бизнеса. А далее он вам поможет составить из них своего рода ТЗ (бэклог продукта) и затем уже наладит результативный процесс общения с разработчиками.
Главное - не ждите, что Scrum-мастер теперь за вас всё сделает. Его задача не в том, чтобы вас заменить. А в том, чтобы повысить эффективность затрат в разработку, в том числе за счет вашего более тесного вовлечениея в неё. Будьте готовы учиться новому. В конце концов, это ваш бизнес. И поэтому, эти изменения не нужны никому так сильно, как вам.
Успехов!
За что же надо платить разработчику, чтобы он работал на бизнес, а не наоборот? Правильный ответ - за изменения в операционном процессе бизнеса, которые ведут к бизнес-результату. Значит всё дело в том, как мы ставим задачи в разработку. Если мы говорим, что нам нужен функционал - то получим вышеописанные проблемы. Если мы приносим описание желаемых изменений в операционном процессе, то уже теплее, но эффективность всё ещё оставит желать лучшего. Идеально - приносить разработчикам причинно-следственную связь между желаемым бизнес-результатом и конкретными изменениями в операционном процессе, чтобы вместе с разработчиками придумать под это нужный функционал.
Но позвольте. Как же с ними общаться? Они же вообще нифига не понимают в бизнесе. А я нифига не понимаю в том, чего они делают и говорят. Как мы найдем общий язык? Антон, ты с дуба рухнул?
Есть такая проблема. Вы вместе с ними обладаете всем необходимым знанием, всеми необходимыми компетенциями. Вы всё понимаете в своём бизнесе. Они всё понимают в технологиях. Но проблема в том, что вы не можете разговаривать и договариваться. Поэтому вам нужен третий. Но не для того, чтобы стать между вами посредником. Так будет ещё хуже. А для того, чтобы помочь вам понять друг друга, найти общий язык, научиться вместе эффективно работать на бизнес-результат.
И это не трекер предпринимателей. Эти товарищи пошлют вас подальше с запросом помочь решить проблему в IT-разработке. Это не консультант по IT-разработке, потому что он непременно пойдет руководить вашими разработчиками. Это несколько IT-ролей в одном человеке:
- коуч: помогает дойти от бизнес-результата до конкретных требований в разработке, и от общих проблем в разработке до конкретных действий по их устранению
- фасилитатор: помогает найти общий язык с IT-шниками
- ментор: приносит провереный IT-менеджерский опыт
- тренер: вместе с вами работает на эффективность в разработке
И, ваша удача, что такие люди на рынке не только есть. Они даже имеют международно признанную сертификацию. И называется эта роль - Scrum-мастер. И его даже не обязательно звать в штат. Можно на время, проектно. А чтобы Scrum не стал карго-культом, как это чаще всего бывает, четко поставьте ему задачу. А именно - опишите желаемый бизнес-результат, на который он будет работать вместе с вами. И когда согласие будет достигнуто, то первое, что вы должны сделать: вдвоем сесть, и расписать ваши гипотезы причинно-следственных связей в операционке вашего бизнеса. А далее он вам поможет составить из них своего рода ТЗ (бэклог продукта) и затем уже наладит результативный процесс общения с разработчиками.
Главное - не ждите, что Scrum-мастер теперь за вас всё сделает. Его задача не в том, чтобы вас заменить. А в том, чтобы повысить эффективность затрат в разработку, в том числе за счет вашего более тесного вовлечениея в неё. Будьте готовы учиться новому. В конце концов, это ваш бизнес. И поэтому, эти изменения не нужны никому так сильно, как вам.
Успехов!
IT-стартап - это изначально высокий риск. Средняя доходность по венчурным фондам в IT-индустрии около нуля. С другой стороны есть же акции и облигации. Есть займы в СМБ, где доходность 20%+ и риск ниже. Наконец, можно пойти в найм в корпорацию или гос органы и заработать там, используя свой успешный предпринимательский опыт. Почему же успешные предприниматели всё равно хотят в IT-стартап?
Успешный предприниматель хочет выйти на следующий уровень. Он уже научился зарабатывать миллионы. Хочет следующий порядок цифр - миллиард. Следующий бизнес-проект должен быть таким, чтобы предыдущий оставался своего рода кубком на полке в офисе.
Традиционные инвестиционные инструменты - акции, облигации и т.д. - не подходят, потому что не позволяют заработать без доступа к инсайдерской информации. Идти работать в корпорацию или в государственные структуры означает для предпринимателя какой-то значительный промежуток времени быть под кем-то, а он не хочет терять качество управления собственной жизнью. Ему важно зайти в такой бизнес-проект, где у него будет возможность делать то, во что он сам верит.
Поэтому IT-стартап. В отличие от оффлайн бизнеса, себестоимость практически равна нулю, масштабирование ограничено только рынком, и, наконец, самое главное - очень высокий потенциальный возврат на вложения денег и усилий. Чтобы взломать логику венчурной отрасли, предприниматель сам идет делать IT-бизнес, стараясь снизить размытие своей доли и использовать свой предпринимательский опыт, чтобы максимизировать вероятность получить ярдовый бизнес. Сам идет делать маркетинг, продажи, сам ищет и привлекает ключевых специалистов.
И правильно делает. Единственное, что ему не хватает - опыта в управлении IT-бизнесом. И вроде как на рынке достаточно отраслевых акселераторов, которые могут либо за небольшую долю, либо за денежку, догрузить нужной экспертизой и по рынку, и по управлению бизнесом в IT. Одна проблема - когда предприниматель успешно дойдет до ограничений, связанных с управлением IT-разработкой, акселератор разведет руками и отправит его искать решение самостоятельно. А между тем проблема с течением времени усугубляется всё сильнее и сильнее. Сложность продукта растет, штат IT-специалистов тоже, подстегивая совокупную стоимость владения продуктом для предпринимателя.
Чтобы процесс разработки был управляем, в нём должно быть:
1. Понятное не IT-шнику видение продукта, продуктовая концепция.
2. Дорожная карта, план версий продукта, согласованный с бизнес-планом.
3. Бюджет разработки на каждую версию (деньги + сроки).
4. Всё это в гибком формате, чтобы можно было легко актуализировать.
5. Какие-то понятные циклы, в рамках которых мы сравниваем план/факт и актуализируем.
Первые 4 пункта я делаю вместе с моими клиентами за 3 часа и 15 тыс руб. Можно разбить на две встречи по 1.5 часа или на три по 1 часу. А дальше для реализации 5-го пункта прекрасно подойдет Kanban-метод со своими каденциями с опциональным включением Scrum-фреймворка для специфичных бизнес-ситуаций. И чем раньше предприниматель всё это сделает, тем раньше ему удастся остановить рост совокупной стоимости владения. В идеале нужно сделать всё это ДО найма специалистов в проект. Но даже если IT-специалисты уже наняты, проблему всё равно удастся решить. Вопрос только насколько быстро и безболезненно для коллектива.
Успехов!
Успешный предприниматель хочет выйти на следующий уровень. Он уже научился зарабатывать миллионы. Хочет следующий порядок цифр - миллиард. Следующий бизнес-проект должен быть таким, чтобы предыдущий оставался своего рода кубком на полке в офисе.
Традиционные инвестиционные инструменты - акции, облигации и т.д. - не подходят, потому что не позволяют заработать без доступа к инсайдерской информации. Идти работать в корпорацию или в государственные структуры означает для предпринимателя какой-то значительный промежуток времени быть под кем-то, а он не хочет терять качество управления собственной жизнью. Ему важно зайти в такой бизнес-проект, где у него будет возможность делать то, во что он сам верит.
Поэтому IT-стартап. В отличие от оффлайн бизнеса, себестоимость практически равна нулю, масштабирование ограничено только рынком, и, наконец, самое главное - очень высокий потенциальный возврат на вложения денег и усилий. Чтобы взломать логику венчурной отрасли, предприниматель сам идет делать IT-бизнес, стараясь снизить размытие своей доли и использовать свой предпринимательский опыт, чтобы максимизировать вероятность получить ярдовый бизнес. Сам идет делать маркетинг, продажи, сам ищет и привлекает ключевых специалистов.
И правильно делает. Единственное, что ему не хватает - опыта в управлении IT-бизнесом. И вроде как на рынке достаточно отраслевых акселераторов, которые могут либо за небольшую долю, либо за денежку, догрузить нужной экспертизой и по рынку, и по управлению бизнесом в IT. Одна проблема - когда предприниматель успешно дойдет до ограничений, связанных с управлением IT-разработкой, акселератор разведет руками и отправит его искать решение самостоятельно. А между тем проблема с течением времени усугубляется всё сильнее и сильнее. Сложность продукта растет, штат IT-специалистов тоже, подстегивая совокупную стоимость владения продуктом для предпринимателя.
Чтобы процесс разработки был управляем, в нём должно быть:
1. Понятное не IT-шнику видение продукта, продуктовая концепция.
2. Дорожная карта, план версий продукта, согласованный с бизнес-планом.
3. Бюджет разработки на каждую версию (деньги + сроки).
4. Всё это в гибком формате, чтобы можно было легко актуализировать.
5. Какие-то понятные циклы, в рамках которых мы сравниваем план/факт и актуализируем.
Первые 4 пункта я делаю вместе с моими клиентами за 3 часа и 15 тыс руб. Можно разбить на две встречи по 1.5 часа или на три по 1 часу. А дальше для реализации 5-го пункта прекрасно подойдет Kanban-метод со своими каденциями с опциональным включением Scrum-фреймворка для специфичных бизнес-ситуаций. И чем раньше предприниматель всё это сделает, тем раньше ему удастся остановить рост совокупной стоимости владения. В идеале нужно сделать всё это ДО найма специалистов в проект. Но даже если IT-специалисты уже наняты, проблему всё равно удастся решить. Вопрос только насколько быстро и безболезненно для коллектива.
Успехов!