Избегаем временного коллапаса, срыва сроков и косых взглядов

23.12.2020

Андрей

люблю читать и писать

Это не всё! Читайте другие части этого кейса.
No items found.
Привет! На днях к нам обратился известный агрохолдинг с задачей разработки нового внешнего продукта, который они выводят на рынок. Ложка мёда была разбавлена бочкой дёгтя: разработку уже передали сторонней команде, но те сорвали все сроки и обоюдно прекратили сотрудничество. Такие истории, в прочем, не новинка на этом рынке. Давайте разберёмся, как не допустить такого факапа со стороны студии. Об очевидных вещах нужно напоминать чаще.

Определите MVP и поставьте задачи

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

Не делегируйте то, в чём не разбираетесь

Нередко в попытках ублажить хотелки клиента студия руководствуется единственным принципом: мы можем всё, за что заплатят. А то, чего не можем, делегируем тем, кто может. Логика данного решения рушится на этапе того, что для правильного делегирования необходимо знать специфику решения задач, которые передаёшь. Если в этой цепочке отвечать за задачу перед вами будет 3 лицо, то перед клиентом нести ответственность вам.

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

Оцените проект

Одна из величайших загадок вселенной, а конкретно срыв сроков проекта, кроется в оценке времени. Тут, на самом деле, нет сложных интегралов: то, что вы будете делать 10 часов, смело умножайте на два. А лучше на три. Если вы сдадите проект раньше, то клиент будет только рад. Если нет, то у него не возникнет неоправданных ожиданий. Но давайте будем реалистами: все мы люди и никто не застрахован от форс-мажоров, болезней, поломки техники или банальных «затыков» в работе. Страховать от этого проект и свою репутацию — ваша забота.

Разбивайте большие задачи на маленькие

Допустим, что у вас задача на две недели. Реальный прогресс в таких тасках сложно контролировать, а удовлетворение от решения скачет вниз как акции печатных изданий. Если задача делается больше дня — её сложно проверить. Если её сложно проверить — необходимо разбить на подзадачи. Это полезно и для отчётности по проекту. Допустим, что чекаут необходимо делать 80 часов. Если он не сделан — он просто не сделан. Если разбить его на 10 задач по 8 часов, то «не сделан» превращается в «готов на 90%». Подумайте, какой ответ менее огорчит стейкхолдеров.

Не все дедлайны можно перенести

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

Если что-то может пойти не так, оно пойдёт не так

Определите модель сотрудничества

Оплаты, если точнее. Тут я выделю три основных, которые мы используем.

Fixed price

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

Time & Material

Самая гибкая с точки зрения требований модель, которая часто применяется в Agile-командах. Подходит сложным проектам и в тех случаях, когда чётко сформированных задач нет. Любые коррективы можно внести в процессе и переиграть сюжет по ходу пьесы. Принцип прост: расчёт идёт относительно стоимости часа конкретного сотрудника. Проект разбивается на небольшие задачи, каждая из которых оценивается в N-количество часов.

Profit-sharing

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

В итоге

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

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

Определите MVP и поставьте задачи

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

Не делегируйте то, в чём не разбираетесь

Нередко в попытках ублажить хотелки клиента студия руководствуется единственным принципом: мы можем всё, за что заплатят. А то, чего не можем, делегируем тем, кто может. Логика данного решения рушится на этапе того, что для правильного делегирования необходимо знать специфику решения задач, которые передаёшь. Если в этой цепочке отвечать за задачу перед вами будет 3 лицо, то перед клиентом нести ответственность вам.

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

Оцените проект

Одна из величайших загадок вселенной, а конкретно срыв сроков проекта, кроется в оценке времени. Тут, на самом деле, нет сложных интегралов: то, что вы будете делать 10 часов, смело умножайте на два. А лучше на три. Если вы сдадите проект раньше, то клиент будет только рад. Если нет, то у него не возникнет неоправданных ожиданий. Но давайте будем реалистами: все мы люди и никто не застрахован от форс-мажоров, болезней, поломки техники или банальных «затыков» в работе. Страховать от этого проект и свою репутацию — ваша забота.

Разбивайте большие задачи на маленькие

Допустим, что у вас задача на две недели. Реальный прогресс в таких тасках сложно контролировать, а удовлетворение от решения скачет вниз как акции печатных изданий. Если задача делается больше дня — её сложно проверить. Если её сложно проверить — необходимо разбить на подзадачи. Это полезно и для отчётности по проекту. Допустим, что чекаут необходимо делать 80 часов. Если он не сделан — он просто не сделан. Если разбить его на 10 задач по 8 часов, то «не сделан» превращается в «готов на 90%». Подумайте, какой ответ менее огорчит стейкхолдеров.

Не все дедлайны можно перенести

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

Если что-то может пойти не так, оно пойдёт не так

Определите модель сотрудничества

Оплаты, если точнее. Тут я выделю три основных, которые мы используем.

Fixed price

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

Time & Material

Самая гибкая с точки зрения требований модель, которая часто применяется в Agile-командах. Подходит сложным проектам и в тех случаях, когда чётко сформированных задач нет. Любые коррективы можно внести в процессе и переиграть сюжет по ходу пьесы. Принцип прост: расчёт идёт относительно стоимости часа конкретного сотрудника. Проект разбивается на небольшие задачи, каждая из которых оценивается в N-количество часов.

Profit-sharing

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

В итоге

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

Другие части этого проекта

No items found.
Если вас это заинтересовало, заполните форму
Сделать также классно:
Расскажите подробнее

При отправке вы даёте согласие на обработку персональных данных.

Спасибо! Совсем скоро ответим.
Упс! Что-то пошло не так. Попробуй ещё раз, или отправь письмо на hire@5x10.co
Если тебя заинтересовала вакансия, заполни форму
Расскажи о себе

При отправке вы даёте согласие на обработку персональных данных.

Спасибо! Не оставим без ответа.
Упс! Что-то пошло не так. Попробуй ещё раз, или отправь письмо на hire@5x10.co

Твоя десница — проводник
в цифровую обитель

Твоя десница — наша отдушина. Рассказываем про продукт, дизайн и маркетинг без сложных эпитетов. Избранные кейсы, личный опыт и nothing more. Присоединяйся!