Забегает молодой парень в больницу:Большая часть проблем возникает из-за недопонимания. Вы ставите задачу подчиненному или смежникам, а потом ругаетесь, потому что люди сделали не то, не так, потому что не так вас поняли. Сталкивались с таким? Если вы менеджер и решение задачи входило в ваш круг обязанностей, то наверняка знаете, что неверное исполнение — это ваша ошибка, а не ошибка исполнителя.
— Доктор, сделайте мне кастрацию, срочно!
— ???
— Срочно, доктор, некогда объяснять!
Доктор делает кастрацию. Наутро парень приходит в себя от наркоза, его спрашивают, в чем дело, собственно?
— Понимаете, я собираюсь жениться на еврейке, у них так принято по религии.
— Так может быть Вам нужно было обрезание?
— А я что сказал?!!!
В заметке собран каркас из вопросов, ответы на которые стоит записать в задаче если вы задачедатель. Если вы исполнитель, то ответы на эти вопросы помогут лучше понять задачу. Для большинства вопросов собраны примеры из практики, негативные и позитивные.
Зачастую причина проблем в том, что задача ставится в терминах «что нужно сделать», а не «какой результат нужно получить» и «зачем этот результат нужен».
Для понимания возможности, трудозатрат и сроков исполнитель будет задавать вам много разных вопросов (особенно, если он не в теме). Переписка съест время, а значит, и деньги. Можно ускорить выполнение задачи, если сформулировать то, что требуется сделать, более развернуто. Но что и как именно нужно развернуть? Далеко не каждому задачедателю это понятно.
Задачи бывают разного типа.
Задачи на исправление дефекта, при котором известно, как должно быть и в чем проявляется ошибка, в данной статье не рассматриваются.
В статье мы разберем задачи на изменения, включая работы в рамках проектов, доработок систем, организационные и другие нестандартные задачи (за рамками остаются задачи типа “реши проблему”, они будут разобраны в последующих статьях), рассмотрим каркас постановки задачи и приведем примеры. Каркас синтезирован из разных методологий и фреймворков.
Исполнитель может выполнять задачу сам, а может управлять командой исполнителей (например, разработчиков).
Задачи могут обладать спецификой.
Задачи на разработку ПО требуют ответов на массу дополнительных вопросов. Мы не будем фокусироваться на специфичных задачах и будем рассматривать общие вопросы, связанные с процессом изменений.
Зачем статья автору?
Я писал этот материал, чтобы в дальнейшем делиться им и использовать его в качестве пособия для руководителей и других коллег, ставящих задачи нашей команде и другим сотрудникам, а также как методичку для входящего контроля качества поступающих задач.
Каркас постановки задачи
Не все пункты нужно описывать, не для каждой задачи, не для каждого исполнителя. Ряд пунктов могут быть зафиксированы в регламентах
Содержательная часть задачи
- Термины и аббревиатуры
- Что сделать
- Зачем
- Уровень задачи (корневая/подзадача)
- (Для подзадачи) В рамках проекта. Какая надзадача (Какую задачу решаете вы, в рамках которой ставите данную подзадачу)
- (Для корневой задачи) Бизнес-эффект
- (Для корневой задачи) Будет достигнут таким-то образом
- (Для корневой задачи), Бизнес-эффект будет измеряться таким-то образом
- Причины уверенности в том, что эта задача позволит получить бизнес эффект
- Если задачу не сделать, то (компания потеряет/недополучит то-то, в таких-то случаях, возникающих тогда-то...)
- Будущие сценарии использования. Клиент (Исполнитель) получит возможность/улучшение … (если он получит). Будущие сценарии использования основных действующих лиц такие-то
- Результаты это задачи нужны чтобы (Как вы планируете использовать результаты этой подзадачи). Декомпозиция решения надзадачи.
- Контекст
- Бизнес-модель (канва), для внешних исполнителей
- Как сейчас это работает (как создается ценность)
- Объем и частота протекающий в рассматриваемой области операций, типовые сроки и параметры операций
- Как это работает у референтов, других внутренних подразделениях. У кого работает так, как планируется изменить (особенно случаи нововведений). Какие есть альтернативы, какие альтернативы исследовали. Какие плюсы/минусы известных аналогичных способов решения задачи
- Чем регламентируется деятельность, какие есть инструкции, базы знаний и какие документы сопровождают деятельность (на входе и на выходе)
- Что мешает достигать целей сейчас, какие причины это вызывают
- По задаче сделано… результаты выложены здесь..
- Критерии готовности
- Нужно это, чтобы воспользоваться этим так-то. Обязательно так как. Способ проверки такой-то …
- Название задачи
Организационная часть задачи
- Заказчик, роль заказчика
- Ответственный (за выполнение), роль исполнителя
- Организатор приемки задачи (для задач типа смежник-смежнику).
- Приоритет/Какое место этой задачи в очереди относительно других
- При ограничениях/При условиях
- Задача особой важности (если это так)
- Разрешено все, что не запрещено/Запрещено все, что не разрешено,
- Дедлайн по задачи такой-то потому-то (если он есть)
- Сроки по задачи такие-то, так как (если есть обоснованные сроки)
- Расходы не более чем Х, потому-что
- С привлечением/без привлечения (ресурсов)
- Переработки допустимы/не допустимы
- Согласование плана
- План согласовать с вами перед выполнением/рассказать после выполнения/не интересует.
- Группа создания/согласования плана изменения(если согласование перед выполнением)
- Участники процесса изменения, роль в изменении, контакты, способ связи. Не забыть основного будущего исполнителя
- Статус согласования изменения (с кем согласовано)
- Пожелания к развертыванию (если нет в регламентах)
- Пожелания к организации развертывания
- Кого уведомить о результатах
- Следующая точка контроля (время, место) (если нет регламентах), что должно быть к ней готово
- Проверяют качество (с кем согласовать) (если нет регламентах)
- Что делать, если пойдет не так (что чего нет в регламентах)
- Что может произойти не так
- Ущерб критический?
- Как не допустить для критического?
- Что в этом случае делать для некритического?
- Как будет производится откат обратно (для изменений)
Требования к заказчику (ресурсы, информация, полномочия)
Заполняется исполнителем при обработке задачи.
Предыстория
Краткий обзор некоторых концепций
Какие распространенные концепции были выявлены при поверхностном поиске?
Концепция SMART описывает свойства, которыми должна обладать достигаемая цель, но увы, она не задает каркаса постановки задачи.
Хорошая краткая статья megaplan.ru/letters/how-to-set-tasks содержит каркас постановки задачи, но в некоторых случаях он не будет полным (впрочем, именно этот каркас был включен в данную статью).
Некоторые параметры задачи были заимствованы из книги “Одноминутный менеджер и обезьяны” (https://habr.com/ru/post/475284/) и других книг про Одноминутного менеджера.
В методе TOTE (годная статья habr.com/ru/post/339556) не хватает описания целеполагания, что очень часто и является причиной последующих недоразумений.
Agile ([5]) указывает причину основных проблем — задачедатели часто “спускают” задачи в виде “что нужно сделать”, хотя гораздо эффективнее указывать в первую очередь, зачем задача вообще нужна и какие результаты нужно получить (ниже будут приведены примеры).
Концепция INVEST описывает свойства задачи и на практике эта концепция полезнее SMART, но опять-таки не определяет каркас.
Важно заметить, что каждая задача не обязательно должна обладать нижеперечисленными свойствами, но чем ближе к ним, тем проще задачу планировать и реализовать.
Приведем эти свойства, чтобы держать их в голове при постановке задачи. (Подробно о концепции [7])
В целом в постановку задачи включены некоторые тезисы agile[6]:
Для разработки ПО больше всего подходит каркас user story, но у него есть минус: он чаще формулируется командой разработки или product owner, исходя из болей и нужд персоны клиента, не являющейся конкретной личностью. Это слабо применимо к задачам разработки ПО для внутреннего клиента.
При разработке ПО для внутреннего клиента чаще всего есть какой-то главный менеджер, который ставит задачи для данного ПО, но дополнительно есть масса смежников, которые также ставят задачи. В отличии от персоны погрузиться во все нюансы деятельности всех смежников очень непросто, особенно если их не учили формулировать задачи. Так почему бы не научить их формулировать задачи в понятном формате, похожем на user story?
В примерах ниже все персонажи вымышлены, а совпадения с реальными людьми или ситуациями случайны (но это не точно).
Концепция SMART описывает свойства, которыми должна обладать достигаемая цель, но увы, она не задает каркаса постановки задачи.
Хорошая краткая статья megaplan.ru/letters/how-to-set-tasks содержит каркас постановки задачи, но в некоторых случаях он не будет полным (впрочем, именно этот каркас был включен в данную статью).
Некоторые параметры задачи были заимствованы из книги “Одноминутный менеджер и обезьяны” (https://habr.com/ru/post/475284/) и других книг про Одноминутного менеджера.
В методе TOTE (годная статья habr.com/ru/post/339556) не хватает описания целеполагания, что очень часто и является причиной последующих недоразумений.
Agile ([5]) указывает причину основных проблем — задачедатели часто “спускают” задачи в виде “что нужно сделать”, хотя гораздо эффективнее указывать в первую очередь, зачем задача вообще нужна и какие результаты нужно получить (ниже будут приведены примеры).
Концепция INVEST описывает свойства задачи и на практике эта концепция полезнее SMART, но опять-таки не определяет каркас.
Важно заметить, что каждая задача не обязательно должна обладать нижеперечисленными свойствами, но чем ближе к ним, тем проще задачу планировать и реализовать.
Приведем эти свойства, чтобы держать их в голове при постановке задачи. (Подробно о концепции [7])
- Independent (независимая). Задачу можно реализовать отдельно от другихи, при этом она будет нести ценность.
- Negotiable (обсуждаемая). Задача не содержит детальное, подписанное ТЗ. При постановке детали не требуются, они могут быть обсуждены позже.
- Valuable (полезная, несущая ценность). Задачи должны быть полезны для бизнеса. Если задача полезна для сотрудника, но не приносит пользу бизнесу, ее ценность сомнительна.
- Estimable (поддающаяся оценке). Задачу “Иди туда, не знаю куда” сложно оценить.
- Small (компактная). Если задачу можно сделать за 1-2 недели, то выполнением этой задачи проще управлять. Большие задачи стоит делить на подзадачи.
- Testable (можно проверить). Выполнение задачи можно проверить.
В целом в постановку задачи включены некоторые тезисы agile[6]:
- Если исполнитель не понимает, зачем он выполняет задачу, то с большой вероятностью сделает ее не так. Если понимает, то, значит, он, кроме всего прочего, лучше мотивирован.
- Если исполнитель не является вашим подчиненным, то к нему приходят задачи из разных подразделений. Понимание того, зачем та или иная задача нужна для компании, особенно если задача делается в рамках кросс-функционального проекта, в котором участвуют несколько подразделений со стороны заказчика, позволит правильно приоритизировать задачу относительно других.
- Если зафиксировано, зачем нужна задача и какие результаты решения ожидаются, то исполнитель сможет проверить, что заказчик предлагает сделать и предложить лучший вариант (так как исполнитель лучше разбирается в своей области деятельности).
Для разработки ПО больше всего подходит каркас user story, но у него есть минус: он чаще формулируется командой разработки или product owner, исходя из болей и нужд персоны клиента, не являющейся конкретной личностью. Это слабо применимо к задачам разработки ПО для внутреннего клиента.
При разработке ПО для внутреннего клиента чаще всего есть какой-то главный менеджер, который ставит задачи для данного ПО, но дополнительно есть масса смежников, которые также ставят задачи. В отличии от персоны погрузиться во все нюансы деятельности всех смежников очень непросто, особенно если их не учили формулировать задачи. Так почему бы не научить их формулировать задачи в понятном формате, похожем на user story?
В примерах ниже все персонажи вымышлены, а совпадения с реальными людьми или ситуациями случайны (но это не точно).
Описание основного каркаса
Содержательная часть задачи
Что сделать
То, что требуется сделать = список работ, которые нужно осуществить в рамках задачи. Если добавить исполнителя и сроки, то получится план решения задачи. Часто этим и заканчивается постановка.
“Делай это”, — пишет менеджер. Исходя из личного опыта, это — первое, что приходит на ум, когда возникает желание поставить задачу. Записываем, что нужно сделать, а позже вернемся к этому пункту, чтобы уточнить или переписать, если потребуется.
“Сделайте мне кастрацию”.
Возможно, полный список того, что нужно сделать до конца неясен и тогда указываются только первые шаги для решения. Но в этом случае, чтобы не было недоразумений, стоит сделать приписку “определить и сделать такие-то следующие шаги”.
При описании стоит опираться на общеупотребимые термины и аббревиатуры. В противном случае — стоит создать подраздел “Термины и понятия”.
Зачем
Прежде всего, пункт “Зачем” нужен для объяснения исполнителю вашего целеполагания, чтобы, приступая к задаче, он мог проанализировать список работ из “Что сделать” и проверить их на адекватность и полноту и смог лучше понять какую цель вы хотите достичь.
Задача “Сделайте мне кастрацию, потому что я собрался жениться на еврейке, а у них так принято” у грамотного врача вызовет вопрос адекватности формулировки и предотвратит катастрофу.
Во-вторых, описание должно дать понимание приоритетов выполнения этой конкретной задачи.
Представьте себя в роли исполнителя, которому «прилетает множество задач». Какую задачу ему брать первой, как приоритизировать задачи? Если вы — его руководитель, то можете указать приоритеты директивно, но что, если это не так?
Исполнитель может обладать правом принятия решения, что ему делать в первую очередь, а что оставить на потом. В таком случае на него возлагается ответственность за правильность такого выбора.
В рамках кровавого энтерпрайза бывает, что расстановка приоритетов осуществляется, исходя из “оперативной ситуации” или того, что нужнее прямо сейчас, кто громче кричит. Также она может вырождаться в «я тебе, ты мне» или «давай дружить против того-то», но перед лицом генерального директора лучше все же использовать другие способы приоритизации.
Варианты определения очереди выполнения
Первый способ. Сквозные приоритеты.
Если задача решается в рамках проекта, в котором участвуют несколько подразделений компании, и проекты имеют сквозной по всей компании приоритет, то укажите связь с этим проектом (разумеется, предполагается, что список проектов и приоритетов является известным исполнителю, если он участвует в более одном проекте, иначе он не будет понимать за какую задачу браться первой).
Второй способ. С помощью бизнес-показателей.
Если задача выполняется за рамками проекта со сквозным приоритетом, то указание того, как компания, решив задачу первого уровня, увеличивает скорость генерации дохода, сокращает расходы, связанный капитал или увеличивает скорость изменений (см. [3]), дает какую-то общее для вас и исполнителя понимание приоритета (если есть объявленная стратегия развития компании, определяющая, какой из показателей сейчас важнее).
Третий способ. Явное указание руководителем места этой задачи в очереди относительно других
Один из вариантов управления порядком выполнения задач исполнителем — указание очередности выполнения поставленных перед ним задач. В этом случае для новой задачи нужно указать ее место во входящей очереди.
Если задача решается в рамках проекта, в котором участвуют несколько подразделений компании, и проекты имеют сквозной по всей компании приоритет, то укажите связь с этим проектом (разумеется, предполагается, что список проектов и приоритетов является известным исполнителю, если он участвует в более одном проекте, иначе он не будет понимать за какую задачу браться первой).
Второй способ. С помощью бизнес-показателей.
Если задача выполняется за рамками проекта со сквозным приоритетом, то указание того, как компания, решив задачу первого уровня, увеличивает скорость генерации дохода, сокращает расходы, связанный капитал или увеличивает скорость изменений (см. [3]), дает какую-то общее для вас и исполнителя понимание приоритета (если есть объявленная стратегия развития компании, определяющая, какой из показателей сейчас важнее).
Третий способ. Явное указание руководителем места этой задачи в очереди относительно других
Один из вариантов управления порядком выполнения задач исполнителем — указание очередности выполнения поставленных перед ним задач. В этом случае для новой задачи нужно указать ее место во входящей очереди.
Уровень задачи (корневая/подзадача)
Задача — это конкретное мероприятие, имеющее цели по SMART и границы того, что нужно сделать.
Пример задачи с неясными целями: Увеличить продажи в 1 квартале (увеличили на 1 руб = решили задачу?).
Корневая задача направлена на непосредственное получение конечного эффекта (по-другому — задача первого уровня). Эффект может быть выражен в бизнес-показателях, а может, и нет.
Примеры корневых задач
- Запустить в продажу новый продукт “НБР”.
- Сделать автоматическую обработку заказов клиентов (в таком-то случае).
- Сократить время растаможки товара за счет получения таможенного статуса экономического уполномоченного оператора.
- Создать отчет по воронке продаж.
- Организовать корпоративный новый год.
- Провести конференцию по специализации предприятия.
- Пропиарить массовый выезд сотрудников компании на базу отдыха
Если результаты задачи непосредственно влияют на бизнес-показатели, то нужно указать уровень задачи “корневая задача”.
Часто для решения корневой задачи нужна помощь других сотрудников. В этом случае для решения задачи формируют иерархию подзадач.
Если результаты задачи нужны для решения какой-то корневой задачи, то нужно указать уровень “подзадача”.
Надзадача/проект и зачем вам нужна эта задача (для подзадачи)
Если вы ставите подзадачу в рамках решаемой вами задачи первого уровня, в таком случае нужно указать, какую задачу вы этим решаете.
Если задача выполняется в рамках проекта и есть сквозные приоритеты по проектам, то указание проекта позволяет рабочим центрам выполнять задачи в правильном порядке.
Если вы — исполнитель и используете каркас постановки для выяснения параметров задачи, то можете спросить вас: “А зачем нужна эта задача, как вы воспользуетесь результатом? Мне это нужно знать, чтобы лучше понять, как сделать задачу.”
После получения ответа техника 5Why’s рекомендует погружаться в целеполагание дальше и глубже: “А это зачем вам нужно” и так далее 5 раз.
Представьте себе разговор в магазине спорттоваров
Покупатель: ”Посоветуйте мне беговые кроссовки”
Продавец: “А с какой целью вы планируете бегать?” (1 why)
Покупатель: “Хочу похудеть”
Продавец: “А зачем вам худеть?” (2 why)
Покупатель: “Хочу быть здоровым”
Продавец: “А зачем вам быть здоровым?” (3 why)
Покупатель: “Чтобы быть счастливым”
Продавец: “А зачем вам быть счастливым?” (4 why)
Покупатель: “Вашу мать, я сюда пришел кроссовки купить, так помогите их выбрать”
Продавец: “А с какой целью вы планируете бегать?” (1 why)
Покупатель: “Хочу похудеть”
Продавец: “А зачем вам худеть?” (2 why)
Покупатель: “Хочу быть здоровым”
Продавец: “А зачем вам быть здоровым?” (3 why)
Покупатель: “Чтобы быть счастливым”
Продавец: “А зачем вам быть счастливым?” (4 why)
Покупатель: “Вашу мать, я сюда пришел кроссовки купить, так помогите их выбрать”
В реальности после второго почему, задачедатель начинает сильно нервничать.
Вопрос, который можно задать: “Я понял зачем вам это нужно, (можно повторить ваше понимание зачем). Выберите что мы дальше будем делать: перейдем к обсуждению деталей этой задачи или я могу помочь найти более простые альтернативы решению надзадачи”.
Магазин спорттоваров, дубль 2
Вариант 1
Покупатель: ”Посоветуйте мне беговые кроссовки”
Продавец: “А с какой целью вы планируете бегать?” (1 why)
Покупатель: “Хочу похудеть”
Продавец: “Я понял, вы планируете бегать, чтобы похудеть. Мы можем перейти к детальным вопросам или я могу предложить альтернативные способы похудеть”
Покупатель: “Просто помогите выбрать кроссовки”
Продавец: “Хорошо, вы где планируете бегать: в зале, по асфальту или в лесу?”
….
Вариант 2
Покупатель: ”Посоветуйте мне беговые кроссовки”
Продавец: “А с какой целью вы планируете бегать?” (1 why)
Покупатель: “Хочу похудеть”
Продавец: “Я понял, вы планируете бегать, чтобы похудеть. Мы можем перейти к детальным вопросам или я могу предложить альтернативные способы похудеть”
Покупатель: “Мне действительно нужен совет как еще можно похудеть”
Продавец: “Чтобы лучше ответить на ваш вопрос, мне нужно понять: А в чем причина того, почему вы хотите похудеть?” (2 why)
Покупатель: “Хочу быть здоровым, так как есть проблемы со здоровьем”
Продавец: “То есть у вас есть проблемы со здоровьем. (Все люди хотят быть здоровыми и бессмысленно спрашивать зачем). Для выявления причин проблем нужно сделать анализы, но в нашем магазине это сделать невозможно. Я рекомендую обратится в клинику Х, я знаю там хорошего доктора ХХ, он помог двум моим друзьям избавится от лишнего веса путем диеты и правильных упражнений.”
Покупатель: “Большое спасибо за помощь”
Покупатель: ”Посоветуйте мне беговые кроссовки”
Продавец: “А с какой целью вы планируете бегать?” (1 why)
Покупатель: “Хочу похудеть”
Продавец: “Я понял, вы планируете бегать, чтобы похудеть. Мы можем перейти к детальным вопросам или я могу предложить альтернативные способы похудеть”
Покупатель: “Просто помогите выбрать кроссовки”
Продавец: “Хорошо, вы где планируете бегать: в зале, по асфальту или в лесу?”
….
Вариант 2
Покупатель: ”Посоветуйте мне беговые кроссовки”
Продавец: “А с какой целью вы планируете бегать?” (1 why)
Покупатель: “Хочу похудеть”
Продавец: “Я понял, вы планируете бегать, чтобы похудеть. Мы можем перейти к детальным вопросам или я могу предложить альтернативные способы похудеть”
Покупатель: “Мне действительно нужен совет как еще можно похудеть”
Продавец: “Чтобы лучше ответить на ваш вопрос, мне нужно понять: А в чем причина того, почему вы хотите похудеть?” (2 why)
Покупатель: “Хочу быть здоровым, так как есть проблемы со здоровьем”
Продавец: “То есть у вас есть проблемы со здоровьем. (Все люди хотят быть здоровыми и бессмысленно спрашивать зачем). Для выявления причин проблем нужно сделать анализы, но в нашем магазине это сделать невозможно. Я рекомендую обратится в клинику Х, я знаю там хорошего доктора ХХ, он помог двум моим друзьям избавится от лишнего веса путем диеты и правильных упражнений.”
Покупатель: “Большое спасибо за помощь”
Сделайте мне кастрацию, я женюсь на еврейке.
Бизнес-эффект (для корневой задачи)
Какой бизнес-эффект имеет задача, будем ли мы его измерять и как.
Примеры бизнес-показателей
Типовые бизнес-показатели
Сложно измеримые бизнес-показатели
- Запустить в продажу новый продукт: Увеличение оборота
- Сделать автоматическую обработку заказов клиентов (в таком-то случае): Уменьшение издержек
- Сократить время растаможки товара за счет получения более высокого таможенного статуса: Уменьшение связного капитала
Сложно измеримые бизнес-показатели
- Создать отчет по воронке продаж: Увеличение скорости изменений за счет повышения управляемости
- Организовать корпоративный новый год: Повышение лояльности сотрудников
- Провести конференцию по специализации предприятия: Повышение узнаваемости бренда для клиентов
- Пропиарить массовый выезд сотрудников компании на базу отдыха: Повышение привлекательности компании на рынке HR
Если влияние задачи на бизнес-показатели оценить сложно (например, это улучшение юзабельности интерфейса оператора, не приводящее к ускорению обработки заказа), то стоит указать, почему задача важна для ее потребителя.
Декомпозиция решения надзадачи или как вы планируете использовать результаты задачи
Непростые задачи (например, задачи по интеграции приложений) нужно обсуждать с исполнителями — для выработки декомпозиции вашей задачи (надзадачи) по задачам исполнителей.
Но бывает так, что исполнителю ставят задачу без объяснения того, как вы планируете использовать результаты его работы для решения своей задачи.
Часто это приводит к проблемам: результаты задачи не могут быть использованы в дальнейшем, что ведет к потерям времени или “костылям”, которые приходится переделывать.
Пример
— Купи мне молоток.
— Купил. А зачем тебе молоток?
— Гвоздь в стену забить.
— Стена капитальная, тут нужна дрель.
— Ок, купи дрель.
— Дрель купил. Стену просверлил. Что дальше?
— Вешай телевизор.
— Сюда телевизор не влезает + блики от окна, нужно его поставить тут, а диван передвинуть — сюда. Так ок?
— Ок.
— Купил. А зачем тебе молоток?
— Гвоздь в стену забить.
— Стена капитальная, тут нужна дрель.
— Ок, купи дрель.
— Дрель купил. Стену просверлил. Что дальше?
— Вешай телевизор.
— Сюда телевизор не влезает + блики от окна, нужно его поставить тут, а диван передвинуть — сюда. Так ок?
— Ок.
Зачем это клиенту (потребителю)
Кто является потребителем задачи? Зачем это потребителю?
Почему невесте из анекдота важен обрезанный муж?
Если задача касается клиента, то обязательно стоит указать, зачем это для клиента.
Бывает так, что изменения системы ухудшают опыт взаимодействия клиента с вами. Это происходит из-за стремления некоторых руководителей к локальной оптимизации, особенно если эти руководители не взаимодействуют с клиентом напрямую.
Пример 1. Задача от логистов (продажа электроники).
“Давайте отключим на сайте прием заказов по выходным, наш склад по выходным все равно не работает”.
Более эффективным является организация обработки заказов на выходных и отображение увеличенных сроков поставки, так как в результате мы все-таки получим какое-то количество дополнительных заказов на понедельник. Или организовать работу склада в выходные, если заказов достаточно.
Более эффективным является организация обработки заказов на выходных и отображение увеличенных сроков поставки, так как в результате мы все-таки получим какое-то количество дополнительных заказов на понедельник. Или организовать работу склада в выходные, если заказов достаточно.
Пример 2. Задача от руководителя маркетинга.
“Давайте на каждой странице сайта отображать всплывающее окно онлайн-консультанта, говорят, что это увеличивает продажи.”
На самом деле многих клиентов бесят постоянно всплывающие окна на каждой странице сайта, что приводит к снижению конверсии.
“Давайте на каждой странице сайта отображать всплывающее окно онлайн-консультанта, говорят, что это увеличивает продажи.”
На самом деле многих клиентов бесят постоянно всплывающие окна на каждой странице сайта, что приводит к снижению конверсии.
Пример 3. Задача от финансового директора.
“Давайте заставлять клиента платить за доставку, если он отказывается от товара при получении”.
Контекст задачи. Магазин торгует обувью, зимние ботинки стоят 6к, и при этом оказывается (только бизнес про это не знает), что таблица размеров на сайте не соответствует размерам производителя обуви. Клиент заказывает пару ботинок и не угадывает с размером.
Когда задачу ставили, никто не задумался о интересе клиента.
Должен ли клиент платить за ошибки контента, которые сделал бизнес? Насколько это снизит уровень лояльности клиентов?
“Давайте заставлять клиента платить за доставку, если он отказывается от товара при получении”.
Контекст задачи. Магазин торгует обувью, зимние ботинки стоят 6к, и при этом оказывается (только бизнес про это не знает), что таблица размеров на сайте не соответствует размерам производителя обуви. Клиент заказывает пару ботинок и не угадывает с размером.
Когда задачу ставили, никто не задумался о интересе клиента.
Должен ли клиент платить за ошибки контента, которые сделал бизнес? Насколько это снизит уровень лояльности клиентов?
Будущие сценарии использования
Как основное действующее лицо будет использовать результаты решенной задачи. Каков будущий сценарий использования?
Особенно важно указать, если основное действующее в сценарии лицо — это ваш клиент.
Пример. Оплата через QR-код
Контекст: Банк сделал возможность оплаты через мобильное приложение с помощью сканирования QR-кода через камеру или сканирования картинки в галерее. В интернет-магазине онлайн-оплата пока что организована только через интернет-эквайринг.
Что нужно сделать: Реализовать оплату через QR-код.
Зачем: Оплата через QR-код с помощью мобильного приложения имеет меньшую комиссию, чем через интернет-эквайринг.
Вопрос. Как это будет использовать клиент? Строим сценарии использования.
Сценарий 1 (20% случаев). Клиент открывает письмо на компьютере, после чего с помощью камеры мобильного телефона и приложения сканирует код и производит оплату.
Сценарий 2 (80% случаев). Клиент открывает письмо в мобильном устройстве, делает скриншот экрана (!!!), сохраняет его в галерею, далее загружает мобильное приложение, выбирает картинку со скриншотом, приложение сканирует штрих-код и открывает доступ к оплате.
Не кажется ли вам сложным второй сценарий? Если у клиента будет выбор, как платить( с помощью привычного интернет-эквайринга или с помощью такого сценария), то что он выберет?
Есть ли другой способ передачи нужных параметров в мобильное приложение, не требующее формирования QR-кода? (Да, есть. Технология deeplink). Будет ли в этом случае размер взимаемой комиссии тоже ниже, чем при проведении операции с помощью интернет-эквайринга?(Да, комиссия будет меньше).
Что нужно сделать: Реализовать оплату через QR-код.
Зачем: Оплата через QR-код с помощью мобильного приложения имеет меньшую комиссию, чем через интернет-эквайринг.
Вопрос. Как это будет использовать клиент? Строим сценарии использования.
Сценарий 1 (20% случаев). Клиент открывает письмо на компьютере, после чего с помощью камеры мобильного телефона и приложения сканирует код и производит оплату.
Сценарий 2 (80% случаев). Клиент открывает письмо в мобильном устройстве, делает скриншот экрана (!!!), сохраняет его в галерею, далее загружает мобильное приложение, выбирает картинку со скриншотом, приложение сканирует штрих-код и открывает доступ к оплате.
Не кажется ли вам сложным второй сценарий? Если у клиента будет выбор, как платить( с помощью привычного интернет-эквайринга или с помощью такого сценария), то что он выберет?
Есть ли другой способ передачи нужных параметров в мобильное приложение, не требующее формирования QR-кода? (Да, есть. Технология deeplink). Будет ли в этом случае размер взимаемой комиссии тоже ниже, чем при проведении операции с помощью интернет-эквайринга?(Да, комиссия будет меньше).
Если не сделать
Укажите, что будет (или чего не будет, см “Квадрат Декарта принятия решений”), если задача не будет выполнена. Это нужно для того, чтобы исполнитель лучше понял, к выполнению какой задачи лучше приступать в первую очередь.
Этот неудобный вопрос часто дает самый понятный ответ на вопрос “Зачем”.
Сравните примеры:
- Компания недополучит 0.1% прибыли, что составляет Х млн. руб. в месяц.
- Сотрудник (оператор) будет тратить в среднем 15 минут в день на ручной ввод данных по оплатам, что обходится для компании в 3 000 руб. в месяц.
- Не внедрение доработок по электронной фискальной регистрации чеков по ФЗ-54 повлечет штрафы компании в размере двойного оборота компании.
Если мне не провести кастрацию, я обману свою верующую невесту и ее отца и не получу богатое приданное.
Критерии готовности (результата)
Это описание ожидаемого результата.
В полном виде
“Нужно вот это, чтобы воспользоваться этим так-то. Обязательно, так как… Способ проверки такой-то”.
Нужно
Что за результат вы хотите получить? (То же самое, что definition of done + acceptance criteria).
Когда вы будете считать, что задача готова на 100%?
Регламентация
В компании должен действовать регламент, устанавливающий, что: если исполнитель берет задачу в работу, то он соглашается решать указанную задачу с заданными критериями готовности.
Если он не согласен, то должен указать причины и предложить, как скорректировать критерии приемки, которые, в свою очередь, должен валидировать задачедатель.
Если он не согласен, то должен указать причины и предложить, как скорректировать критерии приемки, которые, в свою очередь, должен валидировать задачедатель.
Чтобы
Для того, чтобы исполнитель согласился с критериями готовности или предложил иной (лучший) вариант оценки работы, он должен понимать, зачем эти критерии нужны заказчику.
Без понимания того, почему тот или иной критерий столь важен, велика вероятность возникновения ситуации, когда исполнитель его проигнорирует (или включит режим итальянской забастовки). Поэтому лучше критерии описывать с учетом фразы “чтобы”.
Обязательно
Не все критерии одинаково важны, какие-то обязательны=must have, какие-то желательны=nice2have (особенно для задач с дедлайнами). Чем больше вы ограничите исполнителей в выборе способа реализации, тем больше риск невыполнения и снижения инициативы сотрудников (либо возможен сценарий, когда исполнитель будет больше дергать вас, заставляя решать проблемы, так как вы его ограничили). Для обязательных критериев стоит указать, почему они обязательны.
Пример. Найти 1С-разработчиков
Руководитель ставит задачу HR-службе.
Что нужно сделать: найти через hh.ru в городе Воронеж разработчиков на 1С.
Зачем: 01 марта стартует проект по разработке сайта для компании Х. Если мы не найдем разработчиков в эти сроки, мы потеряем этот проект, что повлечет потерю Х тыс. рублей прибыли для компании.
Задаем уточняющие вопросы и формируем критерии готовности:
Первый критерий готовности: 01 марта в проекте по разработке сайта для компании Х участвуют 2 разработчика на 1С уровня Middle+, чтобы компания смогла выполнить договорные обязательства по контракту. Срок 1 марта обязателен иначе мы потеряем заказ.
Второй критерий готовности: уровень оклада каждого разработчика — не более 120 000 рублей на руки.
Хм, а можно одному 100 тыс. рублей, а второму — 140 тыс. рублей? С чем связаны ограничения? Оказывается, с нормой прибыли по контракту. Модернизируем условия: суммарный уровень оклада двух программистов — не более 240 тыс. рублей на руки. Обязательно, иначе проект будет убыточен.
Но при чем тут Воронеж?
Третий критерий готовности: Нужно, чтобы разработчики были из Воронежа, так как есть план открытия филиала разработки в этом городе. Зачем? Чтобы создать там офис, где разработчики могли общаться друг с другом, обмениваться знаниями и опытом, создавать командный дух.
Почему именно Воронеж? Нужен крупный город с хорошими ВУЗами, чтобы можно было оперативно расширять штат, а по исследованию (приложен файл) Воронеж — один из топовых городов, у которого не сильное смещение с Москвой по времени. Насколько обязательно в Воронеже? Насколько задача по открытию филиала важнее задачи выполнения контракта? За двумя зайцами гонимся. Поэтому ответ – необязательно.
Модернизируем критерий: «желательно, чтобы разработчики были из одного города, входящего в список, так как имеются планы по открытию филиала разработки в каком-либо из этих городов»
Внимание: выявлен еще один критерий и на этот раз уровня “обязательно”.
4. Критерий готовности. Время пересечения рабочего графика разработчиков должно пересекаться в течении 6 часов с основным графиком команды заказчика (работает с 10-00 по 19-00 по Москве), чтобы иметь возможность оперативно решать вопросы, которые будут неминуемо возникать из-за сложности проекта. Must have, так как у команды исходно слабый навык продумывания задачи наперед и быстро его не развить.
Указанные критерии — некоторый аналог acceptance criteria. Аналогом definition of done могут быть сформулированные требования по атрибутам качества (если в компании налаженные процессы, то эти требования зафиксированы в регламенте, с которым сотрудники ознакомлены):
(Кстати говоря, насколько важно соблюдение условия трудоустройства сотрудника в штат по ТК? Возможно ли заключить договор ГПХ в данном случае? Ответ — да).
Таким образом, сформулированные критерии развязывают HR руки, так как вместо указания, что делать, описываются цели и ожидаемый результат. Ясно, что подобрать хороших сотрудников в штат к заданному сроку важнее, чем взять их в определенном городе. Если поиск не даст нужных результатов, то можно попробовать найти программистов в другом городе, главное — соблюсти пересечение рабочего графика. Если не нашли разработчиков в одном городе, то можно поискать их в разных населенных пунктах.
Выписываем окончательную формулировку и замечаем, что блок “что сделать” писать не нужно, пусть исполнитель определит его сам:
Что сделать: (определит исполнитель)
Зачем: 01 марта стартует проект по разработке сайта для компании Х. Если мы не найдем разработчиков в эти сроки, мы потеряем этот проект, что повлечет потерю Х тыс. рублей прибыли для компании.
Критерии готовности:
Что нужно сделать: найти через hh.ru в городе Воронеж разработчиков на 1С.
Зачем: 01 марта стартует проект по разработке сайта для компании Х. Если мы не найдем разработчиков в эти сроки, мы потеряем этот проект, что повлечет потерю Х тыс. рублей прибыли для компании.
Задаем уточняющие вопросы и формируем критерии готовности:
Первый критерий готовности: 01 марта в проекте по разработке сайта для компании Х участвуют 2 разработчика на 1С уровня Middle+, чтобы компания смогла выполнить договорные обязательства по контракту. Срок 1 марта обязателен иначе мы потеряем заказ.
Второй критерий готовности: уровень оклада каждого разработчика — не более 120 000 рублей на руки.
Хм, а можно одному 100 тыс. рублей, а второму — 140 тыс. рублей? С чем связаны ограничения? Оказывается, с нормой прибыли по контракту. Модернизируем условия: суммарный уровень оклада двух программистов — не более 240 тыс. рублей на руки. Обязательно, иначе проект будет убыточен.
Но при чем тут Воронеж?
Третий критерий готовности: Нужно, чтобы разработчики были из Воронежа, так как есть план открытия филиала разработки в этом городе. Зачем? Чтобы создать там офис, где разработчики могли общаться друг с другом, обмениваться знаниями и опытом, создавать командный дух.
Почему именно Воронеж? Нужен крупный город с хорошими ВУЗами, чтобы можно было оперативно расширять штат, а по исследованию (приложен файл) Воронеж — один из топовых городов, у которого не сильное смещение с Москвой по времени. Насколько обязательно в Воронеже? Насколько задача по открытию филиала важнее задачи выполнения контракта? За двумя зайцами гонимся. Поэтому ответ – необязательно.
Модернизируем критерий: «желательно, чтобы разработчики были из одного города, входящего в список, так как имеются планы по открытию филиала разработки в каком-либо из этих городов»
Внимание: выявлен еще один критерий и на этот раз уровня “обязательно”.
4. Критерий готовности. Время пересечения рабочего графика разработчиков должно пересекаться в течении 6 часов с основным графиком команды заказчика (работает с 10-00 по 19-00 по Москве), чтобы иметь возможность оперативно решать вопросы, которые будут неминуемо возникать из-за сложности проекта. Must have, так как у команды исходно слабый навык продумывания задачи наперед и быстро его не развить.
Указанные критерии — некоторый аналог acceptance criteria. Аналогом definition of done могут быть сформулированные требования по атрибутам качества (если в компании налаженные процессы, то эти требования зафиксированы в регламенте, с которым сотрудники ознакомлены):
- Поиск сотрудников в штат с трудоустройством по ТК со стандартными условиями трудового договора (изложены в регламенте).
- Кандидатов собеседует один из сотрудников из списка (список представлен).
- Кандидаты проходят проверку службой безопасности перед приемкой на работу (ответственный за проверку указан).
- Привлечение кадрового агентства только по согласованию с финансовым директором.
- И т.п.
(Кстати говоря, насколько важно соблюдение условия трудоустройства сотрудника в штат по ТК? Возможно ли заключить договор ГПХ в данном случае? Ответ — да).
Таким образом, сформулированные критерии развязывают HR руки, так как вместо указания, что делать, описываются цели и ожидаемый результат. Ясно, что подобрать хороших сотрудников в штат к заданному сроку важнее, чем взять их в определенном городе. Если поиск не даст нужных результатов, то можно попробовать найти программистов в другом городе, главное — соблюсти пересечение рабочего графика. Если не нашли разработчиков в одном городе, то можно поискать их в разных населенных пунктах.
Выписываем окончательную формулировку и замечаем, что блок “что сделать” писать не нужно, пусть исполнитель определит его сам:
Что сделать: (определит исполнитель)
Зачем: 01 марта стартует проект по разработке сайта для компании Х. Если мы не найдем разработчиков в эти сроки, мы потеряем этот проект, что повлечет потерю Х тыс. рублей прибыли для компании.
Критерии готовности:
- 01 марта в проекте по разработке сайта для компании Х задействованы 2 разработчика 1С уровня Middle+, чтобы компания смогла выполнить договорные обязательства по контракту. Срок 1 марта обязателен, иначе мы потеряем заказ.
- Суммарный уровень оклада двух разработчиков — не более 240 тыс. рублей на руки. Обязательно, иначе проект будет убыточен.
- Желательно, чтобы разработчики были из одного города, входящего в список, так как имеются планы по открытию филиала разработки в каком-либо из этих городов.
- Рабочий график разработчиков должен пересекаться не менее чем на 6 часов с основным графиком команды заказчика (работают с 10-00 по 19-00 по Москве), чтобы иметь возможность оперативно решать возникающие вопросы. Must have, так как у команды исходно слабый навык продумывания задачи наперед, быстро его не развить.
Способ проверки
Стоит указывать, если это не очевидно.
Задача организации новогоднего корпоратива.
Как понять, что закупить для сотрудников? Какой алкоголь? Какие закуски? Какие развлечения заказать? Если опираться на мнение организатора или руководства, то, скорее всего, корпоратив будет неудачным, потому что рядовым сотрудникам вряд ли понравятся устрицы и бастурма.
Если корпоратив организуется для сотрудников, то логичный способ проверки – провести опрос сотрудников после мероприятия. Как только мы это записали, становится ясно, что добиться лучшего успеха можно, если заранее спросить сотрудников (выборочно или всех), чего они хотят больше: устриц/бастурмы или хамона с итальянским пармезаном?
“Нужно, чтобы сотрудники были довольны, так как корпоратив делается для сотрудников. Способ проверки — опрос после корпоратива. Успех — это когда более 90% опрошенных поставили оценку 8 и выше”.
Если корпоратив организуется для сотрудников, то логичный способ проверки – провести опрос сотрудников после мероприятия. Как только мы это записали, становится ясно, что добиться лучшего успеха можно, если заранее спросить сотрудников (выборочно или всех), чего они хотят больше: устриц/бастурмы или хамона с итальянским пармезаном?
“Нужно, чтобы сотрудники были довольны, так как корпоратив делается для сотрудников. Способ проверки — опрос после корпоратива. Успех — это когда более 90% опрошенных поставили оценку 8 и выше”.
Важно указывать критерии готовности результата, а не способ решения задачи. Зачастую это самое сложное, так как очень непривычно выходить в надсистему.
Желательно указывать не отрицательные (чтобы что-то не происходило), а положительные “чтобы”. В совершенной форме.
Пример. Гвоздь в стене
Что нужно сделать: Забить гвоздь в стену.
Зачем: Чтобы на гвоздь вешать сумку, чтобы освободить пол, чтобы обувь не пачкала сумку, как это происходит сейчас.
Контекст: квартира, в ней проживает семья с обычными сценариями использования квартиры. Сейчас сумки складываются на пол, что загрязняет их.
Критерии готовности результата: забитый в стену гвоздь.
Что не так. Данные критерии готовности очень ограничивают исполнителя в достижении цели. А вдруг после забивания гвоздя туда нельзя будет вешать сумку? А если стена не выдержит вес? А если нужно будет повесить две сумки? Возможны другие варианты решения задачи: забить не один гвоздь, а несколько. Повесить вешалку. Купить напольную вешалку. Купить шкаф с организованным хранением обуви и сумок.
Правильный критерий готовности:
Зачем: Чтобы на гвоздь вешать сумку, чтобы освободить пол, чтобы обувь не пачкала сумку, как это происходит сейчас.
Контекст: квартира, в ней проживает семья с обычными сценариями использования квартиры. Сейчас сумки складываются на пол, что загрязняет их.
Критерии готовности результата: забитый в стену гвоздь.
Что не так. Данные критерии готовности очень ограничивают исполнителя в достижении цели. А вдруг после забивания гвоздя туда нельзя будет вешать сумку? А если стена не выдержит вес? А если нужно будет повесить две сумки? Возможны другие варианты решения задачи: забить не один гвоздь, а несколько. Повесить вешалку. Купить напольную вешалку. Купить шкаф с организованным хранением обуви и сумок.
Правильный критерий готовности:
- Есть возможность хранить сумки в прихожей не на полу — так, чтобы сумка не пачкалась обувью. Обязательно, так как грязная одежда неряшлива.
- Есть возможность брать и класть сумки не наклоняясь, чтобы сократить потери времени и лишний раз не напрягать спину. Желательно.
Критерии готовности нужно стараться формулировать в терминах конечного результата, не указывая каким образом должен быть получен этот результат.
Пример. Оплата на сайте с помощью QR кода
Есть возможность для клиента отсканировать QR код оплаты на странице оплаты, перейти в приложение Банка Х и загрузить QR код для того, чтобы оплатить заказ экономя время на ввод реквизитов.
Такой критерий готовности содержит информацию о том, как нужно получить результат. Он сужает пространство решений и может не содержать наиболее эффективное.
Нужна возможность для клиента перейти со страницы оплаты в приложение Банка Х на страницу оплаты заказа с введенными реквизитами, чтобы экономить время на ввод реквизитов.
Такой критерий готовности позволяет задуматься, каким образом достичь результата наиболее просто. В этом примере такой способ есть — это переход через технологию deeplink, который удобнее для клиента чем QR код.
Такой критерий готовности содержит информацию о том, как нужно получить результат. Он сужает пространство решений и может не содержать наиболее эффективное.
Нужна возможность для клиента перейти со страницы оплаты в приложение Банка Х на страницу оплаты заказа с введенными реквизитами, чтобы экономить время на ввод реквизитов.
Такой критерий готовности позволяет задуматься, каким образом достичь результата наиболее просто. В этом примере такой способ есть — это переход через технологию deeplink, который удобнее для клиента чем QR код.
Контекст
Контекст — это некоторое описание ситуации, как есть сейчас (As is).
Если исполнитель не в курсе ваших текущих процессов, то он зачастую не поймет, что же вам действительно нужно.
- Что за бизнес
- Как рассматриваемая деятельность ведется сейчас
- Как ведется рассматриваемая деятельность у референтов
- Что плохого в текущей ситуации
Примеры с более понятным контекстом
Посоветуйте тех, кто оказывает услуги доставки комнатных растений по Москве с хорошим уровнем сервиса? Нужно, чтобы были созданы приемлемые для комнатных растений условия хранения и перевозки.
Примеры с менее понятным контекстом
Как упаковывать товар для маркетплейсов типа Wildberries, OZON, Беру и т.д. Кто и какие коробки использует, где их брать?
О доставке каких товаров идет речь? Стеклянные бокалы? Матрасы? Кухни? Готовый суп? Условия упаковки отличаются. Придется переспрашивать.
Коллеги, кто работает с обязательной маркировкой, пожалуйста, поделитесь: какие аспекты процесса упаковки являются для вас наиболее острыми и какую информацию вы хотели бы получить.
Об упаковке какого товара речь? Алкоголь? Обувь? Техника? По разным типам товара разные принципы упаковки с разными аспектами. Придется переспрашивать.
О доставке каких товаров идет речь? Стеклянные бокалы? Матрасы? Кухни? Готовый суп? Условия упаковки отличаются. Придется переспрашивать.
Коллеги, кто работает с обязательной маркировкой, пожалуйста, поделитесь: какие аспекты процесса упаковки являются для вас наиболее острыми и какую информацию вы хотели бы получить.
Об упаковке какого товара речь? Алкоголь? Обувь? Техника? По разным типам товара разные принципы упаковки с разными аспектами. Придется переспрашивать.
Что за бизнес (для внешнего исполнителя)
Ставя задачу внешнему исполнителю, стоит предоставить базовую информацию о том, что из себя представляет ваш бизнес.
Бывает, что достаточно написать “Магазин Пятерочка”, и исполнителю станет понятно, о чем идет речь в задаче (если область, где протекают рассматриваемые в задаче процессы близка к опыту исполнителя).
Если же нет, то стоит указать бизнес-канвы (canvas) [см. 8]:
- Тип бизнеса
- Что такое ваш продукт, (товар), какие виды продуктов бывают (кредитование, ОСАГО, страхование, ...)
- в чем специализация бизнеса, какое изюминка (УТП), в чем ценность (доставляем качественный товар в сжатые сроки)
- Кто ваши потребители (розничный клиент, дистрибьютеры, магазины, ...)
- Каналы взаимодействия (розничный магазин, интернет-магазин, внешние маркетплейсы, сетевая торговля, ...)
- Способ монетизации (продажа, лизинг, рассрочка, кредит, ..)
- Способ поддержки потребителей (программы лояльности, рассылки, ...)
- Способ создания ценности через ваши ключевые партнеры (склады, логистика, ...) и ваши ресурсы (магазины)
Например, задача внедрения CRM
Что нужно сделать: Внедрить CRM.
Зачем: Для увеличения повторных продаж.
Понятно ли, что делать? Нет.
Почему нет? Рассмотрим варианты:
Компания 1.
— Потребители: салоны продажи кухонь
— Продукт: кухонная фурнитура
— Каналы взаимодействия: прямые продажи через персональных менеджеров, заказ оформляется через сайт (30%), по телефону (10%), по email/мессенджеры (30%), при встрече (30%)
— Монетизация: продажа с отсрочкой платежа на фиксированное время
— Партнеры: итальянские заводы, грузоперевозчики Европа-Россия, склады в Европе
— Ресурсы: сеть складов в России
— Деятельность: формирование и поддержание ключевого товара на складах, перевозка
Компания 2
— Потребители: физлица
— Продукт: продукты питания
— Каналы взаимодействия: розничные магазины
— Монетизация: оплата при получении товара
— Партнеры: изготовители продуктов, грузоперевозчики
— Ресурсы: сеть розничных магазинов, технологи
— Деятельность: организация производства натуральных продуктов без консервантов, быстрая доставка и продажа
Компании 1 нужна классическая “B2B” CRM система, с фиксацией лидов, переговорами по ценам и скидкам, резервированием товара и отгрузки, интегрированная с телефоном, почтой, мессенджерами и имеющая мобильную версию или приложение.
Компании 2 нужна “розничная” CRM с программой лояльности, промодвижком, сценариями автоматической сегментации и рекламы через email, sms, web-push, интегрированная с кассой, телефонией и сайтом.
Зачем: Для увеличения повторных продаж.
Понятно ли, что делать? Нет.
Почему нет? Рассмотрим варианты:
Компания 1.
— Потребители: салоны продажи кухонь
— Продукт: кухонная фурнитура
— Каналы взаимодействия: прямые продажи через персональных менеджеров, заказ оформляется через сайт (30%), по телефону (10%), по email/мессенджеры (30%), при встрече (30%)
— Монетизация: продажа с отсрочкой платежа на фиксированное время
— Партнеры: итальянские заводы, грузоперевозчики Европа-Россия, склады в Европе
— Ресурсы: сеть складов в России
— Деятельность: формирование и поддержание ключевого товара на складах, перевозка
Компания 2
— Потребители: физлица
— Продукт: продукты питания
— Каналы взаимодействия: розничные магазины
— Монетизация: оплата при получении товара
— Партнеры: изготовители продуктов, грузоперевозчики
— Ресурсы: сеть розничных магазинов, технологи
— Деятельность: организация производства натуральных продуктов без консервантов, быстрая доставка и продажа
Компании 1 нужна классическая “B2B” CRM система, с фиксацией лидов, переговорами по ценам и скидкам, резервированием товара и отгрузки, интегрированная с телефоном, почтой, мессенджерами и имеющая мобильную версию или приложение.
Компании 2 нужна “розничная” CRM с программой лояльности, промодвижком, сценариями автоматической сегментации и рекламы через email, sms, web-push, интегрированная с кассой, телефонией и сайтом.
Как решается эта задача сейчас, кто ее решает
Указание состояния As Is покажет исполнителю, что, собственно говоря, нужно сделать, какую “пропасть” предстоит преодолеть. В зависимости от текущего состояния работа может сильно отличаться.
Грубо говоря: задача достичь оборота в 1 млн. рублей для компании, имеющей оборот 900 тыс. рублей или имеющей оборот в 100 тыс. рублей — это совершенно разные задачи.
Указание того, кто занимается решением задачи сейчас, сразу обозначит ключевого исполнителя, который обладает наибольшим объемом информации по задаче.
Если аналог задачи уже решен в соседнем подразделении или у референтной компании, это также стоит указать.
Пример. Сделать расчет сроков доставки
Что нужно сделать: реализовать расчет сроков доставки для клиента на сайте
Зачем: определенность в сроках доставки увеличивает конверсию интернет-продаж.
Как решается задача сейчас:
Случай 1. Менеджер при обработке заказа видит в ERP системе плановые сроки доставки и указывает их клиенту.
Случай 2. Менеджер при обработке заказа связывается с логистами и узнает, когда поедет машина. Логисты накапливают заказы на складе и отгружают, когда их накопилось достаточно. Обозначенные клиенту сроки регулярно срываются.
В первом случае достаточно отобразить известную информацию на сайте.
Во втором случае нужно перестроить процессы, обеспечив регулярность в ущерб себестоимости (если задача того стоит, что пока не известно). Плюс автоматизировать процессы планирования. Только после этого что-то можно делать на сайте. Сроки и трудозатраты этих задач отличаются в 10-50 раз.
Зачем: определенность в сроках доставки увеличивает конверсию интернет-продаж.
Как решается задача сейчас:
Случай 1. Менеджер при обработке заказа видит в ERP системе плановые сроки доставки и указывает их клиенту.
Случай 2. Менеджер при обработке заказа связывается с логистами и узнает, когда поедет машина. Логисты накапливают заказы на складе и отгружают, когда их накопилось достаточно. Обозначенные клиенту сроки регулярно срываются.
В первом случае достаточно отобразить известную информацию на сайте.
Во втором случае нужно перестроить процессы, обеспечив регулярность в ущерб себестоимости (если задача того стоит, что пока не известно). Плюс автоматизировать процессы планирования. Только после этого что-то можно делать на сайте. Сроки и трудозатраты этих задач отличаются в 10-50 раз.
Чем регламентируется деятельность и какие документы сопровождают деятельность
Например. При автоматизации обработки заказа нужную информацию часто можно найти в инструкции менеджера, которую выдают при приеме на работу.
Что мешает достижению цели сейчас
Почему существующими способами с учетом нужных параметров качества нельзя достичь тех же целей.
Пример. Сделать расчет сроков доставки
Что нужно сделать: реализовать расчет сроков доставки для клиента на сайте.
Зачем: определенность в сроках доставки увеличивает конверсию интернет-продаж.
Как решается задача сейчас:
В карточке товара отображается общая таблица сроков доставки.
Менеджер при обработке заказа видит в ERP системе плановые сроки доставки и указывает их клиенту.
Вариант 1. Что мешает: сроки в карточке товара не связаны с фактическим наличием товара, так как товарные остатки не загружаются на сайт.
Что нужно сделать: Наладить импорты остатков и цепей поставок на сайт и сделать алгоритм расчета сроков доставки.
Вариант 2. Данные по остаткам, складам, цепям поставок загружаются на сайт, но алгоритм расчета и отображение данных в карточке товара отсутствуют.
Что нужно сделать: разработать алгоритм расчета сроков доставки.
Вторая задача в 2-3 раза больше по трудозатратам, чем первая.
Зачем: определенность в сроках доставки увеличивает конверсию интернет-продаж.
Как решается задача сейчас:
В карточке товара отображается общая таблица сроков доставки.
Менеджер при обработке заказа видит в ERP системе плановые сроки доставки и указывает их клиенту.
Вариант 1. Что мешает: сроки в карточке товара не связаны с фактическим наличием товара, так как товарные остатки не загружаются на сайт.
Что нужно сделать: Наладить импорты остатков и цепей поставок на сайт и сделать алгоритм расчета сроков доставки.
Вариант 2. Данные по остаткам, складам, цепям поставок загружаются на сайт, но алгоритм расчета и отображение данных в карточке товара отсутствуют.
Что нужно сделать: разработать алгоритм расчета сроков доставки.
Вторая задача в 2-3 раза больше по трудозатратам, чем первая.
Ранее по задаче сделано…, смотреть здесь
Какие работы по задаче уже проведены и есть ли возможность увидеть формализованный результат.
Название задачи
После создания блоков “Зачем” и ”Критерии готовности” можно записать и название задачи. Оно должно быть коротким, емким и стандартным.
Организационная часть задачи
При условиях (Права и ограничения)
Должна быть принята или указана базовая парадигма (одно из двух):
“Разрешено все, что не запрещено” либо “Запрещено все, что не разрешено”.
Регламент
Стоит закрепить регламентом базовую парадигму. В задаче писать исключения из этого правила.
Обычная парадигма — “разрешено, что не запрещено”.
Что же запрещено?
— Говорить неправду клиентам
— Быть самым умным
— Нарушать УК
— Допускать незапланированные расходы компании без согласования с руководителем за рамками вашей ответственности/полномочий.
Что разрешено:
— Спрашивать совета у более опытных сотрудников, включая руководителя
— Привлекать экспертов, не являющихся сотрудниками
— Использовать базу знаний компании и всю мощь интернета для поиска информации
— Привлекать других сотрудников для решения подзадач
— Говорить “Нет”, приводя логические аргументы
Кроме того, в организации должны быть закреплены общие правила работы:
Обычная парадигма — “разрешено, что не запрещено”.
Что же запрещено?
— Говорить неправду клиентам
— Быть самым умным
— Нарушать УК
— Допускать незапланированные расходы компании без согласования с руководителем за рамками вашей ответственности/полномочий.
Что разрешено:
— Спрашивать совета у более опытных сотрудников, включая руководителя
— Привлекать экспертов, не являющихся сотрудниками
— Использовать базу знаний компании и всю мощь интернета для поиска информации
— Привлекать других сотрудников для решения подзадач
— Говорить “Нет”, приводя логические аргументы
Кроме того, в организации должны быть закреплены общие правила работы:
- Если тебе звонят в рабочее время, но ты занят и не можешь взять трубку, перезвони, как освободишься. Если на том конце занято, напиши в чате.
- Вопросы, не требующие немедленного ответа, обсуждай в чате, а не по телефону (кроме вопросов взаимоотношений).
- Вопросы взаимоотношений обсуждай по телефону или при личной встрече.
- Видишь проблему — реши ее.
- Если столкнулся с проблемой, то подумай самостоятельно, как ее решить — не менее 15 минут с минимальными расходами/усилиями. Не придумал, напиши руководителю и обсуди с ним. Пока не поговорил с руководителем, эта проблема — твоя проблема (Критикуешь — предлагай).
- Если столкнулся с проблемой и придумал, как ее решить самостоятельно, и расходы компании в рамках твоих полномочий/ограничений, то напиши про проблему, способ решения и начало выполнения руководителю и далее решай ее. Руководитель, если нужно, вмешается. Если это требует расходов выше твоих полномочий/ограничений, то согласуй план выполнения с руководителем (Предложил — делай).
- Если задержался в дороге более 15 минут, пиши об этом и причинах в чат, в группу/канал.
- Если уходишь в отпуск/плановое отсутствие, найди того, кто будет замещать тебя на это время.
- И т.п.
Насколько срочно?
Если задача имеет высокую срочность, укажите это и поясните, почему задача имеет такую срочность. Например, если задача нужна для организации “Черной пятницы”, то укажите это и срок, когда наступит черная пятница.
Встречаются особые дедлайны, после наступления которых задача объективно не нужна. Например, срок выступления на конференции. Например, если нужен лендинг для рекламной компании, то deadline для него — это время оплаченной рекламы, которую нельзя сдвинуть.
Для задач типа разработка ПО, почему важно указывать deadline только там, где он действительно есть, и чем отличается управление такими задачами
Разработка ПО — высокорискованная деятельность. Бывает так, что реализация выходит за оценку срока реализации в пять и более раз по объективным причинам. Зачастую оценить с хорошей точностью срок реализации задачи = на 90% сделать ее.
Для высокорискованных видов деятельности управление задачами с дедлайнами и без дедлайнов сильно различается.
Для задачи без deadline исполнитель будет управлять методом фиксированного скоупа = стараться сделать все то, что указано в критериях приемки, даже если это выходит за ожидаемые сроки. В этом есть смысл, так как если задача окупается без привязки к срокам, то нет смысла останавливаться на полпути.
Если у задачи есть deadline, то исполнитель управляет методом фиксированного срока. В первую очередь он оценивает, возможно ли задачу сделать к этому сроку и что именно возможно сделать с заданной командой. Если оценка выполнения выходит за рамки заданного срока, то нужно обсудить с заказчиком варианты выхода из ситуации.
Типовые варианты решения задачи “успеть в срок”:
Допустим, есть риск увеличения сроков в два раза и задачу “успевают сделать впритык”. В таком случае нужна декомпозиция задачи на подзадачи, а затем разделение задачи на два подтипа — must have и nice2have. Must have подзадач должно быть не более половины от всех подзадач. В противном случае высок риск того, что задача не будет выполнена в срок. Относиться к этому можно так: must have сделают, а далее, если успеют, то что-то из nice2have.
Для высокорискованных видов деятельности управление задачами с дедлайнами и без дедлайнов сильно различается.
Для задачи без deadline исполнитель будет управлять методом фиксированного скоупа = стараться сделать все то, что указано в критериях приемки, даже если это выходит за ожидаемые сроки. В этом есть смысл, так как если задача окупается без привязки к срокам, то нет смысла останавливаться на полпути.
Если у задачи есть deadline, то исполнитель управляет методом фиксированного срока. В первую очередь он оценивает, возможно ли задачу сделать к этому сроку и что именно возможно сделать с заданной командой. Если оценка выполнения выходит за рамки заданного срока, то нужно обсудить с заказчиком варианты выхода из ситуации.
Типовые варианты решения задачи “успеть в срок”:
- увеличение команды, если сроки — более 2-3 месяцев
- реализация “на костылях” = увеличение технологического долга
- сокращение требуемого функционала (scope), разделение на части must have и nice2have (см. ниже и “Критерии готовности”)
Допустим, есть риск увеличения сроков в два раза и задачу “успевают сделать впритык”. В таком случае нужна декомпозиция задачи на подзадачи, а затем разделение задачи на два подтипа — must have и nice2have. Must have подзадач должно быть не более половины от всех подзадач. В противном случае высок риск того, что задача не будет выполнена в срок. Относиться к этому можно так: must have сделают, а далее, если успеют, то что-то из nice2have.
Задача особой важности
Если реализация задач поставлена у исполнителя на конвейер, то бывает нужно проталкивание некоторых задач быстрее, чем обычно.
Выделите такие задачи меткой “Особый контроль”, которая позволит исполнителю по-другому организовать работы по управлению задачей, а задачедателю отдельно отслеживать такие задачи. По каждой такой задаче свяжитесь с исполнителем и проговорите ее важность, чтобы у исполнителя это отложилось. Но помните — таких задач не должно быть много.
Почему это требуется и откуда берутся задержки в выполнении обычных задач?
Обычно выполнение входящих задач организуют конвейерным способом: исполнитель берет следующую задачу из входного буфера, выполняет, передает следующему рабочему центру до тех пор, пока задача не будет решена. Разбор возникающих проблем организован через руководителя или самоорганизованной командой. Проблемы и исключения диагностируются через стендапы и отчеты.
Такой способ организации позволяет обеспечить лучшую продуктивность команды, но при этом конкретная задача может быть сделана не самым быстрым образом. К примеру, задача может пролежать значительное время в ожидании следующего рабочего центра или может зависнуть у исполнителя до тех пор, пока она не появится в контрольных отчетах и не станет проблемой.
Некоторые задачи особо важны для бизнеса, по ним нельзя допускать подобных задержек, поэтому для них формируется отдельный подпроцесс.
Например:
Все эти методы повышают управляемость, но снижают продуктивность, так как больше времени тратиться на непродуктивные статусы и контрольки. Поэтому таких задач должно быть мало, не более чем одна из пяти, иначе конвейер производства перестает быть конвейером и общая продуктивность падает.
Такой способ организации позволяет обеспечить лучшую продуктивность команды, но при этом конкретная задача может быть сделана не самым быстрым образом. К примеру, задача может пролежать значительное время в ожидании следующего рабочего центра или может зависнуть у исполнителя до тех пор, пока она не появится в контрольных отчетах и не станет проблемой.
Некоторые задачи особо важны для бизнеса, по ним нельзя допускать подобных задержек, поэтому для них формируется отдельный подпроцесс.
Например:
- эти задачи явно обсуждаются при каждом стендапе,
- они в приоритете в буфере следующего рабочего центра,
- они решаются наиболее сильным исполнителем из рабочего центра,
- любые проблемы сразу же эскалируются на менеджеров,
- к задаче “приделываются ноги” — прикрепляется ответственный менеджер, который отслеживает все проблемы по этой задаче.
Все эти методы повышают управляемость, но снижают продуктивность, так как больше времени тратиться на непродуктивные статусы и контрольки. Поэтому таких задач должно быть мало, не более чем одна из пяти, иначе конвейер производства перестает быть конвейером и общая продуктивность падает.
Ограничение по деньгам
Для задач с лимитом по расходам укажите этот лимит. Лимит может означать как ненужность задачи, если расходы выйдут за лимит (покупка материалов дороже, чем продажа готового изделия), так и другие причины.
Наличие лимита влияет либо на scope, либо на сроки.
Например:
- Подарок на день рождения нужно купить на собранную сумму.
- Доработки собственного сайта можно делать в перерывах между проектами (бесплатно, так как ФОТ уже оплачен).
- Внедрение корпоративного портала можно откладывать, если нет подрядчика, готового сделать это за минимум.
- Закупку запасных ноутбуков можно проводить по минимальной цене, которую можно какое-то время ждать.
- Закупку лицензий у вендора можно проводить в конце отчетного периода, когда вендор склонен дать скидку (чтобы показать больший оборот по продажам в этом периоде, если у них внедрен KPI по обороту).
С привлечением/без привлечения ресурсов (Ограничения и права по ресурсам)
Если для решения задачи исполнителю может потребоваться привлечение дополнительных сотрудников, а они перегружены, это может стать проблемой.
В этом случае стоит указать “Решай самостоятельно” или “Не отвлекай такого-то сотрудника”.
Обратная ситуация: некоторые задачи обязательно должны решаться блестяще, для чего нужно привлечь эксперта. Тогда указываем “Привлеки такого-то сотрудника”.
Например, “Напиши статью для интернета для такого-то сайта, информацию возьми у такого-то эксперта по такому-то случаю”.
Если в компании запрещено привлекать внешних экспертов, но для выполнения данной задачи это требуется, стоит указать это.
Например, “Найти senior разработчика на Java с опытом Hybris, для выполнения привлеки кадровые агентства”.
Согласование способа выполнения
Выберите одно из трех:
- Согласовать план перед выполнением.
- Рассказать после выполнения.
- Не интересует.
Почему это важно? Если вы не доверяете исполнителю, а вам нужно выполнить задачу с первого раза, то стоит попытаться разобраться, как именно она будет решаться до начала работ. Это займет время, но в результате вы получите приемлемое качество работы.
Когда требуется согласование способа выполнения? В случаях, когда риск провала велик настолько, что грозит серьезными потерями (например, вашим увольнением или потерей доверия к вам руководству). Также стоит задумываться об указании данного пункта для некоторых сложных задач, поставленных перед сотрудником, который делает их для вас в первый раз.
(В [4] этот пункт называют страховкой).
Задача “Сделайте мне кастрацию”
Доктор, расскажите мне, что конкретно вы будете делать.
Пример. Организуй вечером в офисе пиццу.
Ставите такую задачу новому сотруднику? Согласуйте перед выполнением!
“Я закажу доставку из пиццерии Х”.
“Не не не. К нам приедут важные заказчики, поэтому закажи в таком-то ресторане”.
Что такое “рассказать после выполнения”?
“Какая вкусная пицца. Расскажи, где заказал”.
Или
“Какая гадость. Где ты это купил? Не покупай там больше”.
“Я закажу доставку из пиццерии Х”.
“Не не не. К нам приедут важные заказчики, поэтому закажи в таком-то ресторане”.
Что такое “рассказать после выполнения”?
“Какая вкусная пицца. Расскажи, где заказал”.
Или
“Какая гадость. Где ты это купил? Не покупай там больше”.
Пример организации “Черной пятницы”
Как не надо делать
— Организуй промоакцию “Черная пятница”.
— (через некоторое время запускается “Черная пятница”). Аааа, у нас сайт не работает, эти ИТ-ники опять сломали сайт.
— А какая нагрузка легла на сайт?
— Такая-то.
— Это на Х% больше того, что выдерживает сайт. Вы льете дорогой платный трафик на неработающий сайт. Вы разве подготовили сайт к таким нагрузкам? А еще сегодня утром пришла повестка в суд за незаконное использование фото телезвезды, и мне пришлось краснеть сегодня утром на правлении.
Как надо делать
— Организуй промоакцию “Черная пятница”. Согласуй план перед выполнением.
— (через некоторое время). Вот план действий, которые нужно выполнить. Разместить баннер на сайте, сделать рассылку (и т.п.) ….
— А какой баннер предлагаешь разместить?
— Прошлогодний, на него был хороший отклик.
— Но мы не можем использовать прошлогодний баннер, на нем было фото Гарика Х, у нас вышел срок контракта с ним, по которому мы можем использовать его фото на наших рекламных материалах, а за новый контракт он запросил неприемлемую для нас сумму. Требуется съемка с новой звездой. Представь мне три варианта к следующему разу.
Идем дальше. А какая планируется посещаемость на сайте?
— Думаю, в пять раз больше обычной, так как мы задействуем новые более эффективные каналы привлечения.
— А ИТ готово к увеличению трафика на сайте?
— Не знаю, я не спрашивал.
— У нас сайт рассчитан на трехкратную нагрузку, поэтому на период “черной пятницы” необходимо провести работы по ИТ, добавьте в план и запросите стоимость увеличения. — Возможно ИТ запросят слишком дорого и дешевле будет сократить рекламный трафик.
— Организуй промоакцию “Черная пятница”.
— (через некоторое время запускается “Черная пятница”). Аааа, у нас сайт не работает, эти ИТ-ники опять сломали сайт.
— А какая нагрузка легла на сайт?
— Такая-то.
— Это на Х% больше того, что выдерживает сайт. Вы льете дорогой платный трафик на неработающий сайт. Вы разве подготовили сайт к таким нагрузкам? А еще сегодня утром пришла повестка в суд за незаконное использование фото телезвезды, и мне пришлось краснеть сегодня утром на правлении.
Как надо делать
— Организуй промоакцию “Черная пятница”. Согласуй план перед выполнением.
— (через некоторое время). Вот план действий, которые нужно выполнить. Разместить баннер на сайте, сделать рассылку (и т.п.) ….
— А какой баннер предлагаешь разместить?
— Прошлогодний, на него был хороший отклик.
— Но мы не можем использовать прошлогодний баннер, на нем было фото Гарика Х, у нас вышел срок контракта с ним, по которому мы можем использовать его фото на наших рекламных материалах, а за новый контракт он запросил неприемлемую для нас сумму. Требуется съемка с новой звездой. Представь мне три варианта к следующему разу.
Идем дальше. А какая планируется посещаемость на сайте?
— Думаю, в пять раз больше обычной, так как мы задействуем новые более эффективные каналы привлечения.
— А ИТ готово к увеличению трафика на сайте?
— Не знаю, я не спрашивал.
— У нас сайт рассчитан на трехкратную нагрузку, поэтому на период “черной пятницы” необходимо провести работы по ИТ, добавьте в план и запросите стоимость увеличения. — Возможно ИТ запросят слишком дорого и дешевле будет сократить рекламный трафик.
Следующая точка контроля (вашего контроля)
Процесс выполнения сколь-нибудь длинных задач нужно контролировать.
Если задача ставится исполнителю, то зачастую в первую очередь нужно контролировать наличие компетенций для выполнения задачи (см. [10]).
Если есть возможность проконтролировать выполнение задачи через имеющуюся на руках отчетность, это прекрасно, сделайте заметку в календаре и проверьте (или попросите руководителя отдела отчетности подготовить к этому моменту отчет с аналитической запиской). Но чаще всего готовой отчетности нет.
Способ контроля работ зависит от способа организации работ у исполнителя и должен быть закреплен в регламенте.
Самый простой способ — определение хотя бы одной следующей точки контроля (работающий для одной задачи высшего приоритета).
Кратко о контроле в разных вариантах управления людьми и командами
Сотрудники или команды, которым вы даете задачи, решают не одну задачу. Если сотрудник ничего не сделал к точке следующего контроля, то часто это из-за того, что он делал другую более приоритетную задачу.
Почему более приоритетная задача съела больше времени? Подробнее смотрите когнитивное искажение “Ошибка планирования” [5] и вариации трудозатрат исполнения задач [9]. (Если бы каждый сотрудник в 100% случаях корректно оценивал свои временные затраты на выполнение задач, то это была бы не оценка, а факт. Известный способ получить оценку плановых трудозатрат разработчика — умножить его собственную оценку на пи).
Организационный контроль выполнения задач, зависит от способа организации работы команды. Стоит определить стандартные способы нотификации в случае сдвигов сроков.
Базовая нотификация по задаче — изменения статуса самой задачей.
В зависимости от способа организации:
Если задача — это задача на ИТ-разработку функционала, то стоит определить стандартные точки контроля:
Напомню, что любая проверка — это ввод в цепочку реализации дополнительной работы рабочего центра заказчика, что увеличивает сроки реализации.
Если проверка предполагается быть, то укажите, кто будет замещать вас в случае вашего отсутствия из-за болезни или отпуска по этой задаче, поставьте его в известность, так же этот зам должен быть добавлен в нотификацию по задаче. Разумеется, он должен понимать: что это за задача, зачем она вам нужна и мог принять решение, правильно ли сделали эту задачу.
Почему более приоритетная задача съела больше времени? Подробнее смотрите когнитивное искажение “Ошибка планирования” [5] и вариации трудозатрат исполнения задач [9]. (Если бы каждый сотрудник в 100% случаях корректно оценивал свои временные затраты на выполнение задач, то это была бы не оценка, а факт. Известный способ получить оценку плановых трудозатрат разработчика — умножить его собственную оценку на пи).
Организационный контроль выполнения задач, зависит от способа организации работы команды. Стоит определить стандартные способы нотификации в случае сдвигов сроков.
Базовая нотификация по задаче — изменения статуса самой задачей.
В зависимости от способа организации:
- (редкий способ) kanban по очереди = задачи выполняются в рамках порядка поступления. В этом случае это дает возможность прогнозировать сроки выполнения, но не дает возможности быстро выполнять какие-то новые задачи (срочные промоакции, критические ошибки, …), так как они новые задачи будут сделаны после всех задач в работе.
- Kanban по приоритетам = в работу берутся задачи большего приоритета. Заказчика будет волновать, “кто пролез в очередь раньше него” и почему так. Чтобы всем заказчикам было понятно, что происходит, стоит вставлять новые задачи в очередь или менять приоритеты периодически, производя рассылку заказчикам (какие новые задачи, почему такие приоритеты, какие блокирующие задачи взяты вне планов). Удобно разделять все задачи на входе (беклог) на топ (задачи которые могут быть взяты в следующую неделю) и хвост (дальние задачи). Если не проходит итеративное планирование, то следует проводить такую рассылку при каждой вставке задачи перед заданной в топ беклога.
- Работа по итерациям (scrum, адаптированный scrum и т.п...) = команда делает в итерацию определенный пул работ. Нотификация идет при планировании о задачах в итерации и задачах в топе беклога + внеплановых изменениях (кроме блокирующих ошибках).
Если задача — это задача на ИТ-разработку функционала, то стоит определить стандартные точки контроля:
- согласование написанного ТЗ. Заказчику при этом может быть непонятно, как проверить правильность алгоритма или структур данных. Более эффективно – проверка правильности на примерах (тест-кейсах).
- проверка реализованного функционала на тестовом окружении перед его выкладкой на бой
Напомню, что любая проверка — это ввод в цепочку реализации дополнительной работы рабочего центра заказчика, что увеличивает сроки реализации.
Если проверка предполагается быть, то укажите, кто будет замещать вас в случае вашего отсутствия из-за болезни или отпуска по этой задаче, поставьте его в известность, так же этот зам должен быть добавлен в нотификацию по задаче. Разумеется, он должен понимать: что это за задача, зачем она вам нужна и мог принять решение, правильно ли сделали эту задачу.
Кстати, зачем нужен контроль?
Сказка о том как не надо из кровавого энтерпрайза.
Каждую неделю директор проектного офиса контролировал что происходит с проектами путем просмотра плана-факта по проекту по времени и бюджету. Если проект начинал «плыть», то директор громко орал на руководителя проекта. Иногда еще спрашивал «а это пробовали?», как правило РП это пробовал. Видя такое отношение к себе, РП до последнего момента скрывали проблемы проекта, до тех пор, пока не становилось слишком поздно. Если проект факапился, то РП увольнялись. Через два года уволили директора проектного офиса, так как топ-менеджерам нужны результаты, а не оправдания.
Контроль стоит организовывать как помощь в проблемах, с которыми сотрудник не способен справится для решения задачи.
Точка контроля – это время, место и способ контроля.
Место – это как будет происходить коммуникация.
- Зайти в кабинет и показать
- Позвонить и доложить
- Написать в чате и доложить
Регламент по месту контроля
Чаще всего место контроля одинаково по большинству задач, поэтому проще закрепить его в регламенте. В зависимости от критичности задачи, времени (в рабочее время/нерабочее время/время сна), типа задачи и проекта.
Способ контроля – определение того, что нужно контролировать. Чаще всего это выполнение пунктов из плана, если точка поставлена как контроль их выполнения. Но если задача срочная, то возможно контролировать состав промежуточных результатов по задаче в назначенное время, чтобы вы поняли, куда он двигается. Это дольше, зато с первого раза.
Пример. Запуск промоакции.
Решили запустить новую промоакцию через неделю. (Обычно запускали за две недели со всеми проверками).
Варианта два – попробовать успеть или сразу сделать копию старой промоакции. Один день есть на понимание того, как делать и сложно ли это. Если за день понимания не пришло, принимает решение сразу сделать копию старой промоакции.
Способ контроля: исполнитель должен рассказать, как он будет программировать эту промоакцию (просто сроки спрашивать бесполезно, так как разработчики просто согласятся на спущенные сроки, не погружаясь в сложности и не формируя срок снизу).
Варианта два – попробовать успеть или сразу сделать копию старой промоакции. Один день есть на понимание того, как делать и сложно ли это. Если за день понимания не пришло, принимает решение сразу сделать копию старой промоакции.
Способ контроля: исполнитель должен рассказать, как он будет программировать эту промоакцию (просто сроки спрашивать бесполезно, так как разработчики просто согласятся на спущенные сроки, не погружаясь в сложности и не формируя срок снизу).
Как определить следующую точку? Зависит от выбора типа согласования плана выполнения и способа управления.
Для задач особой важности, управляемых индивидуально:
- Если вы согласуете план выполнения перед реализацией, то в момент, когда исполнитель будет представлять этот план и способ выполнения можно и определить точку контроля.
- Если вы не планируете проверять способ выполнения, то пусть исполнитель укажет время и место следующего контроля сам и укажет это.
Для остальных задач — определяется регламентом.
Кто проверяет качество
Обычно первое что стандартизируется в компаниях – это контроль качества.
Например. Качество созданного программного кода проверяет тестировщик и иногда руководитель разработки. Юридическую чистоту и соответствие договора достигнутым договоренностям проверяет юрист. При заключении контракта вы просите, исполнителя верифицировать у юриста договор и в следующей точке контроля смотрите на комментарии юриста.
Вы контролируете качество не сами, а с помощью другого сотрудника. Типовые центры контроля стоит записать в регламенте.
Пример регламента.
- Правильность оформления платежных документов проверяет бухгалтер,
- расходы более Х рублей в месяц согласует финансовый директор,
- правильность написанного кода – тимлид.
Но если процессы еще совсем не налажены, либо если задача нетиповая, то стоит указать кто и что будет контролировать.
Пример нетиповой задачи.
При поиске нового разработчика на незнакомом языке программирования стоит пригласить разработчика на том же языке из другой компании, который может собеседовать соискателя.
Что если пойдет не так
Пример. Купить одинаковые подарки на новый год, сумма – 2000 руб. на ребенка. А если 2050 руб – покупаем?
Стоит задуматься и указать:
- Насколько можно перерасходовать
- Насколько можно задержать
- Какой минимум можно сделать (это причина необходимости разбиения критериев готовности на must have, nice2have).
Если нельзя перерасходовать, сделать обязательно все и в заданный срок с высоким качеством, то часто более-менее сложная задача обречена на неудачу. Почему? Когнитивное искажение “Ошибка планирования” толкает вас и исполнителя думать над оптимистичным успешным сценарием выполнения задачи, не задумываясь о возможных проблемах. Но проблемы случаются. Если подумать про них заранее, то можно, во первых, более трезво оценить сроки и требуемые ресурсы.
Во вторых это позволит более быстро реагировать в случае наступления этих проблем. Почему это возможно.
Например. Если не указать допустимые отклонения, то по умолчанию, исполнитель будет бегать к вам по каждому случаю, когда что-то идет за рамками заданных ограничений. Каждый такой случай ведет к задержкам минимум из-за коммуникаций (вы же сидите не без дела), что срывает сроки.
Что может пойти не так и как на это реагировать (и нужно ли реагировать)? Большинство рисков стандартны и должны быть описаны в регламентах.
Регламент
- Заказчик не отвечает на сообщения (через стандартный канал коммуникаций) по уточнению задачи в заданные сроки. Что делать исполнителю? Звонить? В какие периоды? Назначать встреч? Доступен ли календарь заказчика? Уточнять у зама? Он есть?
- Исполнитель заболел, отсутствует по семейным и пр. Что он должен в этом случае делать? Что он должен сделать с вашей задачей? Кого информировать? Кто должен определять зама?
- Исполнитель недопонял задачу и ему нужна доп. информация. Через какой канал с вами связаться, что ему делать если вы не отвечаете, есть ли у вас заместитель? Имеет ли он право делать задачу как считает правильным, чтобы добиться той же цели (выполнены пункты зачем, критерии готовности, способы проверки и ограничения по срокам и деньгам).
- Заказчик заболел. Кто замещает заказчика? Нужен регламент для сотрудников заболевающих, уходящих в отпуск и т.п. Если сотрудник принимает какие-то решения относительно работ другого сотрудника, ему нужен заместитель
Почему автор не называет этот пункт риски
Разумеется, этот блок — это риски и работа с ними. К сожалению, редко кто умеет с ними работать. Возможно проблема в излишней абстракции и отсутствии практических упражнений в местах, где учат менеджеров. Пробуем заменить термины.
Группа создания решения (плана решения)
При выработке решения некоторых задач должны быть учтены чьи-то интересы. Если это так, то укажите список ответственных (т.н. стейкхолдеров). Если это не общеизвестно, укажите кто из них обладает большей экспертизой.
Для ряда задач эти лица могут быть определены исполнителем самостоятельно исходя из рабочего процесса.
Но иногда эти лица не определены явно. Чтобы избежать ситуации, когда чьего то мнения забыли спросить, нужно указать список.
Примеры задач, где неочевидны стейкхолдеры
- Организация новогоднего корпоратива или массового выезда на природу,
- Изменения штатной структуры,
- Улучшение процесса производства,
- Изменение внутренней архитектуры сайта, если ядро разработчиков не определено, его нужно определить.
Пожелания к организации развертывания
Некоторые изменения нельзя вводить в произвольное время. Если нет регламента, то нужно указать эти ограничения.
Например, изменения в коде сайта нужно делать, когда на сайте минимум пользователей, чтобы минимизировать потери заказов.
Кого и как уведомить о решении
Если регламентом не определено, то стоит указать, когда результаты.
Бывает, что люди оказались не в курсе, хотя решение задачи их касается. Если такое возникает, то стоит указать явно.
Например, изменение регламента о работе с задачами Jira касается сотрудников всех подразделений, организующих свою работу через Jira. При этом сотрудники должны подписаться под изменением этого регламента.
Исполнитель
Исполнитель — это сотрудник, взявшийся за исполнение задачи. Он может не быть известен при постановке задачи и определен позднее, например, в случае если задачи такого типа делают несколько людей одной группы.
Организатор приемки задачи
Выполненные задачи проходят приемку сотрудника, того, кто поставил задачу. Задачедатель получил, что хотел?
Но на чьей стороне при этом ответственность за задачу? Исполнитель работу сделал (мячик передал?), задачедатель взял задачу на проверку (действительно взял?).
Если задача поставлена через task-tracker, то есть поле текущий ответственный, которое определяет на чьей стороне мячик.
Но если нет, то бывает так, что задачи надолго зависают, особенно если нет правил и регламентов (который полезен и при наличии task-tracker).
Регламент по приемке задач.
Если задачедатель — более высоко стоящий менеджер (с большими погонами), чем исполнитель, то ответственный за приемку исполнитель (и пока “босс” не принял результаты, исполнитель должен его “попинывать”).
Если задачедатель — менее высоко стоящий менеджер (с большими погонами), чем исполнитель, (так, бывает), то ответственный за приемку задачедатель. (“босс” свое слово сказал, дальше думайте сами).
Почему так: чем более вышестоящий менеджер, тем более он завален мячиками (обезьянами) и тем большим узким звеном он становится в процессе изменений.
Если задачедатель и исполнитель имеют одинаковый уровень, то по умолчанию ответственный за приемку — задачедатель (почему бы и нет).
Если регламента нет и это не первая задача заказчика исполнителю, то можно опереться на предыдущий опыт взаимодействия.
Если задачедатель — менее высоко стоящий менеджер (с большими погонами), чем исполнитель, (так, бывает), то ответственный за приемку задачедатель. (“босс” свое слово сказал, дальше думайте сами).
Почему так: чем более вышестоящий менеджер, тем более он завален мячиками (обезьянами) и тем большим узким звеном он становится в процессе изменений.
Если задачедатель и исполнитель имеют одинаковый уровень, то по умолчанию ответственный за приемку — задачедатель (почему бы и нет).
Если регламента нет и это не первая задача заказчика исполнителю, то можно опереться на предыдущий опыт взаимодействия.
Переработки допустимы
Переработки сотрудников должны быть оплачены, если работодатель их требует (по закону). Сотрудник при этом может задержаться на работе своему желанию, но будет ли оплачена такая переработка — зависит от организации.
Процессом переработок нужно управлять = выделять задачи, которые нужно сделать в срок, в том числе за счет переработок от обычных задач которые делаются в рабочее время.
Требования к заказчику
Исполнитель может указать, что ему нужно от заказчика для успешного выполнения задачи.
В двух словах, требуется:
- Информация
- Ресурсы
- Полномочия.
Например. Для запуска сайта интернет-магазина, заказчик должен подготовить для ИТ компании, создающей сайт, информацию по товарным карточкам с указанием цен.
Этот раздел мы не расписываем подробно.
Описание процесса постановки
Как менеджер дает задание исполнителю?
Менеджер решает поставленные перед ним задачи или проблемы путем построения в голове модели решения, декомпозируя задачу на подзадачи или определяя следующую подзадачу. После этого дает задания исполнителям, собирает результаты, снова ставя задачи и так далее пока не решит проблему/задачу, за которую он отвечает. Результаты исполнения его задачи либо напрямую влияют на бизнес-показатели, либо нужны кому-то для улучшения бизнес-показателей либо ему кажется что задача нужна, но «почему» он себя еще не спрашивал.
Допустим, менеджер – это вы.
Самое важное в задаче – дать качественную описательную часть задачи.
- Пишем, что нужно сделать. В голове есть модель решения задачи (осознанная или не осознанная). Нельзя резко ломать навык, но этого и не нужно. (контекст мышления – креатив).
- Затем переключаемся на вопрос Зачем. Зачем это нужно вам, как вы это будете использовать. Какую задачу решаете вы. Что даст решение этой задачи для компании. И другие пункты если в них есть смысл. (контекст мышления – созерцание).
- Критерии готовности. Сотрудник приходит к вам и говорит, что он все сделал. Что вы его спросите, как поймете, что все что нужно для решения этой задачи сделано и вы получили все что нужно для решении вашей задачи? В этот момент происходит переключение контекста мышления – на критическое мышление. Выписываем критерии, а потом думаем – что критично для решения задачи, а что нет. Как конкретно вы будете проверять (способы проверки эффективности).
- Возвращаемся на пункт «Что нужно сделать». Часто этот блок теперь нужно переписать/дописать.
- Пишем название задачи в систему управления задачами.
Не все пункты описания задачи обязательны. Обязательность зависит от самой задачи и уровня исполнителя (менее опытному нужно писать более подробные постановки). Наиболее важны пункты «Зачем» и «Критерии готовности». Но поначалу стоит смотреть на список пунктов для каждой задачи.
Что описывать зависит от уровня исполнителя.
Если исполнитель — джун/новичок то скорее всего он не знает что и как сделать, чтобы добиться результата. Для таких людей важнее блок “Что сделать”.
Если исполнитель обладает достаточным опытом и ему можно делегировать задачу, то ему достаточно написать “Критерии приемки” (как образ результатов) и он сам придумает как ему достичь этого.
И для того и другого важен блок “Зачем”, дающий целеполагание и мотивацию.
Исполнитель при приеме задачи указывает что ему нужно от заказчика для выполнения задачи и происходит торг между заказчиком и исполнителем.
Примеры
Ниже выписан ряд примеров. Некоторые примеры совсем неприглядные, но все они основаны на реальных событиях, имевших место быть некоторое время назад в разных компаниях с разными задачетаделями и исполнителями.
Будем обозначать З — задачедатель, И — исполнитель.
Пример. Заполнить данные масштаба для населенных пунктов
Что сделать: Заполнить на боевом сервере все значения параметра YZOOM у населенных пунктов = 11. У Москвы и Питера установить 9.
Зачем: Чтобы у пользователей карта с наличием товара в магазинах отображалась в нормальном масштабе.
В рамках проекта Внедрение самовывоза из магазинов
Если задачу не сделать, то клиент видит карту в минимальном приближении (весь мир), что затрудняет ему навигацию на телефоне одним пальцем и приводит к снижению конверсии
Критерии приемки: Открываем сайт в городах по умолчанию, на вкладке “Наличие в магазинах” у одного товара, который есть только в одном магазине карта открывается так, что виден центр города.
Сроки по задаче: сделать до Х числа, так как в это время будет включен весь функционал самовывоза на боевом сайте
Пример 1. Перенести баги из Google.Docs программы в Jira
З: Есть Google Docs таблица, в которой тестировщики фиксировали задачи по исправлению дефектов по сайту. Перенеси эти задачи из Google Docs в Jira (новая систему управления задачами).
И: Перенес. И что делать с ними дальше? Тестировщик говорит, что они не актуальны.
З: Тогда переносить не нужно было
И: Ты сказал перенести, я и перенес.
З: Думать надо было “зачем я это делаю”. Если не знаешь зачем ты что-то делаешь, не делай.
Мораль. В данной задаче можно догадаться о критериях готовности: все задачи из таблицы занесены в виде задач в новую систему управления задачи. Зачем? Этот пункт не был указан, что привело к потере сил и времени.
Как было правильно поставить задачу
Что сделать: Есть Google Docs таблица, в которой тестировщики фиксировали задачи по исправлению дефектов по сайту. Перенеси эти задачи из Google Docs в Jira (новая систему управления задачами).
Зачем: В Jira должны быть заведены все актуальные задачи по исправлению дефектов из обнаруженных ранее.
Критерии приемки:
- В Jira заведены задачи по исправлению дефектов с соблюдением нового регламента написания дефектов, чтобы можно было исправлять дефекты в правильном приоритете.
- В Jira нет дублей дефектов, чтобы не создавать конфликтов исправлений дефектов..
- Новые задачи должны быть актуальны, чтобы разработчики не тратили время.
Пример 3. Разработчик-разработчику
З: Держи задачу
Что сделать: Проанализировать и отрефакторить кусок кода.
Зачем: По результатам мониторинга обнаружен проблемный кусок кода. Он сильно тормозит загрузку сайта, делая его неюзабильным.
Критерии готовности: В куске кода должен делаться один запрос к БД, результаты которого должны кешироваться.
И: Я не знаю что делать. Исправить этот кусок кода можно разными способами, какой выбрать?
З: Думай сам
И — пошел эскалировать на руководителя У.
Собрали обсуждение.
И: Задачу можно решать разными способами, например способ 1, способ 2, способ 3 (далее описаны способы на программистском языке).
З: Нам нужно решить задачу максимально быстро, заплаткой, чтобы успеть к черной пятнице.
И: Ну тогда это способ 1.
З: А какое влияние на бизнес имеет этот способ?
И: При изменении цен, данные на сайте по ценам будут не обновленные в течении часа.
З: Так как изменение цен происходит ночью, в период минимальной активности клиентов, то этот способ допустим.
Что не так: Была обозначена проблема, но не было обозначено что с ней делать, как ее решать, исполнителю дан выбор как сделать задачу самому. При этом недостаточно обозначена цель — сделать как можно быстрее, чтобы успеть к черной пятнице (ЧП), исполнитель не смог выбрать.
Так же решение задачи “успеть к ЧП” это не тот тип задачи, цена ошибки (успех всей компании), она слишком велика. Поэтому обязательно было добавить шаг в критерии приемки: “Согласовать план решения перед выполнением”.
Черная пятница наступает через две недели. Задачу нужно держать на особом контроле, так как нет права опоздать. Дописываем «На особом контроле».
Оптимизация во многом исследовательская задача с неясным объемом работ. Исследования нужно ограничивать по времени, поэтому добавляем «завтра в 9:20 связываешься и проверяем статус решения».
Пример 4. Разработчик-разработчику
З. Улучши этот кусок кода. Вот тебе диагностика из профилировщика
И. Улучшил. Вместо 32 запросов делается 17.
З. Должно быть 0 запросов, данные должны полностью браться из кеша
Мораль. Не указано зачем нужна задача, но в контексте, так как основная задача всей команды – ускорение сайта, но это и не требуется. Но не указаны критерии готовности.
Переписываем
Что сделать: Улучшить этот кусок кода по диагностике из профилировщика
Зачем: Ускорить сайт
Критерии приемки: Все запросы должны работать по кешу, если данные в кеше есть
Пример 5. Начальник разработчиков — разработчику
З. Разберись, как работает этот кусок кода
И. ….
З. Прошел час, где результаты?
И. Я решал другую задачу
Что не так: Без указания важности задачи исполнитель не понял, какая задача приоритетнее.
Есть известный треугольник управления: Ресурсы — Скоуп — Время.
Ресурсы. Исполнитель (если это не менеджер, который может привлечь к выполнению кого-то другого кроме себя) может опираться только на себя, ресурс задан.
Остается выбор — скоуп или время.
Исследовательские задачи (к примеру, разберись с тем что происходит) обычно сложно оценить по трудозатратам, а исследование оптимизации может занимать недели (включая изучение и апробацию новых библиотек и технологий), поэтому исследовательскими задачами управлять нужно с помощью времени.
Эта задача важна потому-то. Бросай все и делай, через час контроль.
Переформулируем задачу:
Что сделать. Разобраться, как работает кусок кода.
Зачем. По данным профилировщика, этот кусок замедляет загрузку страницы на 7 секунд, что блокирует запуск сайта в бой
Критерии приемки. Рассказать логику работы этого кода и дать комментарии, как его исправлять
Приоритет (начальник может определять приортет) – бросаешь все остальные задачи, так как эта единственная задача блокирующая запуск сайт задача
Контроль – через час позвонишь и доложишь, что удалось узнать.
Пример 6. Подключение сервиса ремаркетинга на сайте
Product owner ставит задачу.
Что сделать: Подключите сервис ремаркетинга для сайта.
Зачем: Рекомендации позволят повысить продажи за счет рекламы в интернете.
Критерии готовности: На боевом сайте на всех страницах сайта установлен счетчик, создающий события по при открытии страниц у всех клиентов (у кого не стоит блокировщик рекламы).
Заказчик: специалист по прямому интернет-маркетингу.
Что забыли в этот раз? Поскольку задача выглядит несложной, в работу ее взял новый не очень опытный разработчик и вставил этот скрипт в синхронное выполнение перед открытием страницы сайта в браузере у клиента. Как результат — страницы сайта начали загружаться медленнее на 1.5 секунды, а когда скрипт счетчика начал выдавать ошибки, страницы перестали открываться вообще. Директор ecommerce в ярости.
Product owner, как и любые другие бизнес-заказчики, не задумался (если бы бизнес про это думал, то он плохо бы работал как бизнес) о быстродействии и отказоустойчивости. Эти критерии не прописаны в требованиях, да и документированных требований для сайта нет и никто даже на словах не проинструктировал разработчика об этом.
Как выходить из таких ситуаций: формализовывать нефункциональные требований, а пока идет процесс формализации, проводить обсуждение задачи с разработчиком и тестировщиком, при котором разработчик рассказывает как он будет делать задачу, а тестировщик не забудет спросить то, как предлагаемый способ реализации повлияет на атрибуты качества (производительность, быстродействие, отказоустойчивость, безопасность и т.д.).
Пример 7. Исправление ошибок механики промокодов
Задача: “Сейчас на сайте ошибка, скидки за промокоды за подписку суммируются со скидками за спец.предложения, исправьте”.
Описана проблема, но не описано что нужно сделать.
После выяснения у заказчика, что имелось в виду задача была переписана следующим образом:
Что сделать:
— Придумать механизм определения как сайт должен применять промоакции в случаях, когда в одной корзине есть несколько разных промоакций.
— Учесть возможность как суммирования скидок, так и возможность применения скидки с более высоким приоритетом.
— Провести А/Б тестирование что компании выгоднее — суммировать скидки (больший оборот, но меньшая маржа) или оставлять одну скидку.
Зачем
Последняя акция, проходившая с 01.09 по 01.10 было 1100 заказов, в которых были применены промокоды за подписку и куплен товар со спец предложениями, чего не должно быть, что повлекло потерю в размере Х млн рублей, которую можно было бы предотвратить. При этом не было бы потери оборота, так как значительность скидки по спец предложениям достаточно, чтобы клиенту не требовалась дополнительная мотивация (это гипотеза).
Если не сделать этого, то следующие компании (проводимые для увеличения количества подписчиков), планируемые в феврале и июне дадут потери оцениваемые в ХХ рублей.
Критерии приемки
Возможность управления как взаимодействуют друг с другом промокоды и промоакции без участия программистов.
Механизм А/Б тестирования вариантов взаимодействия.
После такой постановки исполнителю стало понятно, что задачу решать не нужно, так как в апреле планируется перевод функционала расчета промоакций на централизованное программное решение, что обесценит решение этой задачи.
Пример задачи от и до. Оптимизируйте площадь склада на 15%
Приведем пример полного описания постановки (местами избыточной).
Контекст
Бизнес-канва (за рамками постановки, для читателя)
— В2В дистрибьютор,
— продающий мебельную фурнитуру (петли, пантографы, выдвижные ящики и полки, системы хранения (разобранные))
— качественных брендов из Германии с невысокой наценкой
— оптовым клиентам (локальные дистрибьюторы, мебельные салоны-магазины, самозанятые мастера),
— через заказ на сайте и через прямой контакт с менеджером
— с оплатой при продаже или в рассрочку (В2В)
— имеющая скидки, зависящие от суммы сделки и договорные условия с клиентом;
— путем закупки у фабрик, перевозки и импорта внешней транспортной компанией, растаможки внешними силами, хранения на своем Московском складе, отгрузке по Москве своим транспортом и за Москвой заказным транспортом.
Описание ситуации
Как сейчас это работает: Есть свой склад, на котором на на разных стеллажах храниться разный товар. Склад не учитывает ABC.
Объем и частота операций: 10 отгрузок в день, одна отгрузка — от каблучка до газели.
Как работает у референтов: у них склад оптимизирован для разного типа оборачиваемости товара.
Чем регламентируется деятельность: (регламенты складского сотрудника приложены).
Что мешает достигать цели сейчас: не было проведено работы по оборачиваемости товара. Весь товар хранили одинаково.
По задаче сделано: проведены переговоры с арендодателями, достигнута договоренность о снижении коста. Проведен АБС анализ, который выявил 30% низкооборачиваемого товара.
Где посмотреть формализованные результаты: протокол переговоров переговор в приложении. АБС анализ приложен к задаче, поартикульно.
Что сделать
Путем уплотнения хранения сегмента С высвободить площади и подготовить их для передачи арендатору.
Зачем
— Подзадача задачи “Сократить расходы за счет оптимизации склада за счет проведенного АВС анализа”.
— Бизнес-эффект будет достигнут на 100 000 руб в месяц, за счет сокращения площади аренды склада.
— Обоснование расчета: АВС анализ показал наличие 30% низкооборачиваемого товара. Давайте сократим площадь занимаемую этими товара вполовину за счет уплотнения хранения.
— Результаты нужны для передачи высвобожденной площади арендодателю.
— Если задачу не сделать, токомпания будет платить на 100 000 руб/мес больше, что делает компанию недостаточно прибыльной
— Будущие сценарии работы: складские работники более плотно хранят наименее оборачиваемые товары.
Критерии готовности
— Площадь для передачи с нашей стороны освобождена и готова к передаче арендодателю.
— Получен подписанный акт о передаче и подписанный допник с арендатором, чтобы было юридически зафиксированы новые условия.
— Зафиксировано снижение арендной ставки склада на 15%, чтобы мы платили меньше. Процент снижения рассчитан примерно, так путем предположительного уплотнения в два раза товаров сегмента С. При сокращении на 5% работа смысла не имеет.
— План реорганизации выработан и согласован с учетом рекомендаций эксперта Семена Семеновича, чтобы проверить максимальное высвобождение площади при условии сохранения производительности склада.
Организационная часть задачи
Заказчик: cобственник компании.
При ограничениях/в условиях:
— Денежные ограничения: расходы на реорганизацию не должны превышать профита от уменьшения ставки аренды за полгода.
— Временные ограничения: сроки реорганизации — 2 месяца, так как этого времени должно быть достаточно (договорились с арендодателем на эти сроки).
— Привлечения доп. ресурсов допустимы в рамках бюджета.
Согласование плана
— Перед выполнением согласовать план реорганизации с собственником.
— Группа создания плана (с кем должен быть согласован, кого уведомить): начальник склада, начальник отдела продаж, финансовый директор.
— Контакты группы (представлены).
— Коммуникация: через what's up, сделана группа.
— Статус согласования изменения: со всеми согласовано.
Пожелания к развертыванию: проводить в рабочее время, чтобы не платить за переработки.
Следующая точка контроля: на очередной планерке раз в неделю.
— Что должно быть готово к следующей точке контроля: товары группы С разделены на группы по габаритам и хрупкости, сделан расчет возможности уплотнения.
Проверяют качество: начальник пожарной безопастности, менеджер по охране труда.
Как будет производится откат обратно, если это не сработает: передвинем все обратно. Для этого план должен предполагать эту возможность.
Что делать, если пойдет не так
Что может пойти не так
— Затянутся сроки. Для результата некритично. Что будем делать: передоговоримся с арендодателем.
— Может повредится товар при перемещении. Для результата некритично. Как предотвратить: проинструктировать людей про бережное отношение с ценным товаром.
— Новая организация хранения может заблокировать работу склада. Для результата критично, чтобы этого не допустить, план реорганизации должен быть согласован с начальником склада и найденным собственником экспертом по организации складского хранения.
Дополнения
Стандартные критерии готовности
Некоторые критерии готовности могут быть пропущены, если в компании выработаны стандарты критериев готовности по разным типам задач.
Примеры стандартов критериев готовности, в зависимости от типа задачи:
Тип задачи — любая задача
— Результаты выполнения согласованы с заказчиком задачи
— Если по задаче обещаны сроки, то изменение сроков согласуются с заказчиком задачи
— Если по задаче происходит срыв обещанных сроков, то исполнитель ставит в известность заказчика задачи и предлагает следующие шаги для достижения указанных целей (Зачем) как можно раньше, но не позднее конца следующего рабочего дня
Тип задачи — доработка ПО
— Доработанный программный код развернут (установлен) на боевые сервера и доступен к использованию
— На боевых серверах проведены все необходимые настройки для корректного обеспечения работоспособности процесса
— Доработка не ухудшает сформированные ранее системные (нефункциональные) требования (ниже немного раскрывается что это такое)
— Перед деплоем на боевые сервера документация службы поддержки актуализирована
— К изменению ПО приложено краткое описание что изменилось и пункты документации поддержки, где это указано
— Актуализирована документация First Day Analyst и First Day Developer
— Изменения интеграций согласовано с ИТ архитектором
Пункт по соответствие нефункциональным требованиям можно раскрыть:
— ПО должно быть удобным (выполняются UX guideline),
— Интерфейсы работы для клиента должны быть согласованы с product owner, дизайнером, системным аналитиком,
— Интерфейсы работы для сотрудника компании (не розницы) должны быть согласованы с руководителем сотрудника,
— Интерфейсы работы для сотрудника розничного магазина компании должны быть согласованы с ответственным за технологическое развитие розницы,
— ИТ система должна иметь такие-то параметры производительности и не выходить при этом за ограничения по процессору, памяти, I/O и количеству и объему внешних запросов при такой-то нагрузке, таких-то объемах данных, таких-то требованиях на актуальность данных
— ИТ система должна уметь масштабироваться в рамках таких-то условий
Должна быть возможность штатного переноса неактуальных данных ИТ системы в архив, данные из которого доступны в течении такого-то времени для систем отчетности
— ИТ система не должна нарушать законодательство
— ИТ система должна быть защищена от таких-то моделей атак
— В ИТ системе не должны быть захардкожены константы. Они должны быть вынесены и доступны для конфигурирования в виде конфигурационного файла, хранящегося в репозитории либо настройки системы
— Отказоустойчивость ИТ системы должна быть 99% (бизнес любит язык девяток), хотя этот критерий лучше расписать в более понятном для использования виде (см ниже).
Критерии отказоустойчивости в понятном для ИТ виде:
— в случае отказа любого одного элемента серверной конфигурации (сервера, дисковой подсистемы, сетевого маршрутизатора) ИТ система должна продолжать штатно обеспечивать требуемые сценарии,
— в случае отказа внешнего сервиса CRM системы, система может делать недоступным сервисы регистрации, просмотра бонусов, расчета и расходования баллов при покупке, но должна минимально поддерживать основную главную дорогу — позволять оформить заказ с отображением сообщения “Просим прощения, бонусная программа временно не доступна, менеджер свяжется с вами и уточнит сумму списания и начисления баллов
Впрочем, мало сформулировать обширный список, нужно наладить процесс контроля (хотя часто в наших реалиях делают именно так: вводят стандарт, но не могут поставить процесс) К примеру, для выполнения требований по параметрам производительности нужно создать тестовый стенд, нагрузочные скрипты, инструмент для нагрузки и измерения параметров производительности.
Стандартные действия реагирование на риски
— Если сотрудник заболел, то он предупреждает в общем канале коммуникаций заранее или на худой конец, в течении часа отсутствия на рабочем месте, указывая ощущения по выходу на работу, чтобы остальная команда могла организовать работы в которых он участвует, так же учитывая срок отсутствия (ждать или передавать другому).
— Если сотрудник заболел и не уведомил в течении часа, то руководитель проекта узнает у него (в течении часа) и сообщает в общий канал о болезни, чтобы команда могла организовать работы, с учетом планового срока отсутствия (ждать или передавать). Если он не отвечает, то РП пишет в общий канал “Пропал сотрудник, на связь не выходит”, чтобы команда могла передать его работы другому сотруднику.
— Если задача зависла на уволенном сотруднике, то РП должен перераспределить ее на другого сотрудника или передать в буфер какого-то рабочего центра или отменить задачу, чтобы управление задачей не было потеряно и система управления задач не превратилась в помойку
Список литературы
- Cтатья про нефункциональные требования habr.com/ru/post/231961
- Статья про метод TOTE habr.com/ru/post/339556
- Э. Голдратт, Цель. Процесс непрерывного совершенствования. www.ozon.ru/context/detail/id/141279570
- Бланшар, Онкен, Берроуз. Одноминутный менеджер и обезьяны www.labirint.ru/books/682838
- Элиезер Юдковский. Гарри Поттер и методы рационального мышления.
- Паттон Джефф. Пользовательские истории. Искусство гибкой разработки ПО. Кратко здесь: habr.com/ru/post/459872
- Концепция INVEST habr.com/ru/company/luxoft/blog/84030
- Построение бизнес-моделей. Настольная книга стратега и новатора | Пинье Ив, Остервальдер Александр. Кратко: smartarchitects.ru/business-model-canvas, Полно — книга: Пинье Ив, Остервальдер Александр. Построение бизнес-моделей. Настольная книга стратега и новатора |
- Том Демарко и Тимоти Листер «Человеческий фактор. Успешные проекты и команды»
- Практики регулярного менеджмента. Управление исполнением, управление командой. Безручко Павел С.
- Д. Бесков. Какие вопросы задавать Заказчику? medium.com/it-analyst/client-quiestions-30cf76275ad3
Благодарности
Большое спасибо членам клуба КиФБ, особенная благодарность Ivan Kopylov за продуманный и полезный фидбек, а так же Ульяне Леоновой, Даниле Голубцову, Максиму Синксасу, Kseniia Meshkova, Денису Бескову, Serg, Михаилу Сорокину, Step_By_Step, Сергею Титкову и моей жене Наталье за помощь в подготовке статьи, а также большое Ольге Левиной за грамотную корректуру (если найдете ошибки, то это мои ошибки из-за правок финального текста).
И отдельное спасибо Андрею Прудовскому, чьи постоянные придирки заставили задуматься о необходимости думать в терминах результатов и надзадачи перед тем как ставить задачу, что много лет спустя привело к написанию данной статьи.