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

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. Присоединяйся!