Этот пост - продолжение поста Коммуникация с программистами. Как практики стартапов могут помочь ставить задачи

Содержание:

  1. Коммуникация с программистами. Как практики стартапов могут помочь ставить задачи
  2. Как правильно ставить задачи

В этом посте и в следующих двух я постараюсь подробно рассказать о задачах. Как их ставить, как над ними работать, как контролировать задачи. Пост будет полезен для постановщиков задач, исполнителей и руководителей.

Раскроются следующие темы в серии постов:

  1. Что такое задача
  2. Критерии постановки задач
  3. Как ставить задачи правильно
  4. Какие есть проблемы от неправильно поставленной задачи
  5. Что делать если задача неверно поставлена
  6. Почему задача не делается исполнителем и что с этим делать.
  7. Как делать огромные задачи и как делать больше задач
  8. Делегирование задачи
  9. Обратное делегирование задачи
  10. Как хвалить и ругать сотрудников за (не)выполненные задачи

Ок, что такое задача?

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

  1. Почему задача не выполняется, или выполняется долго
  2. Какие есть критерии постановки задач
  3. Как проверить, что задача понята верно
  4. Определяем, что будет в случае выполнения или невыполнения задачи
  5. Как ставить крутые и правильные задачи.

Почему задача не выполняется?

И на это есть несколько причин:

  1. Исполнитель неверно понял задачу. Это происходит из-за недопонимания в общении между вами и исполнителем.
  2. Исполнитель не понимает зачем ему делать эту задачу. Что он получит после ее выполнения? Принесет ли он какую-нибудь пользу или это очередная бесполезная задача от вас?
  3. Испольнитель не знает, как выполнить задачу. Дело не в том, что исполнитель тупой. Дело может быть потому, что задача слишком для него неподъемная и он не знает как ее решить. Или он не знает процессы в вашей организации, или он не знает у кого просить помощи.

Чтобы не было проблем выше, исполнитель должен ответить себе на вопросы:

  1. Что я должен сделать? Тут должен быть описан конечный результат. Что должно получиться после того, как он выполнит задачу.
  2. Зачем мне это нужно. Какой профит он получит после выполнения этой задачи. Прокачает ли он свои скиллы, или принесет пользу бизнесу в облегчении жизни пользователю. Пока не будет ответа на эти вопросы - действовать он врятли начнет.
  3. Как я могу это сделать. И кому задавать вопросы, если я забуксую.

Критерии постановки задач

  1. Должен быть описан результат, который можно как-то измерить. Например: “Повысить план продаж”.
  2. Ок, как понять, что я повысил план продаж? - говорит исполнитель.
  3. Если мы превысим текущий план продаж на 10%. - отвечает постановщик.
  4. Ок, ну тогда так и ставь задачу: Повысить план продаж на 10%.
  5. Срок. Любая задача должна быть четко измерена во времени. Тут может возникнуть недопонимание. Например постановщик работает только до шести вечера, в тоже время, исполнитель работает до восьми вечера. Приходит срок сделать задачу до завтра. Постановщик подразумевает, что задача будет сделана до шести, в тоже время исполнитель уверен в том, что ее можно сделать до восьми. Чтобы не было таких случаев, нужно четко оговаривать время.
  6. Кто мне может помочь, если я не смогу справиться сам? Иногда человек не может решить задачу сам и ему нужна помощь опытных коллег. Когда в задаче написано о том, кто может помочь человеку в решении его задачи - вы упрощаете ему жизнь и делаете задачу легче.
  7. А правильно ли понял человек задачу? Тут нужно, поговорив с исполнителем задачи, задать ему вопрос: “Расскажи, как ты понял, что тебе нужно сделать?”. Здесь исполнитель должен вам рассказать то, чего нужно достигнуть, в какие сроки, и какие у него есть маневры в сложных ситуациях.

Как ставить правильные задачи разработчикам?

Пункты выше - для сотрудников уровня джуниор, стажер. Задачи, которые подробно и по пунктам расписаны могут быть отвергнуты более опытными сотрудниками. С разработчиками, особенно уровня Middle и выше, нужно общаться совершенно по-другому. С ними эффективнее общаться на языке проблем. То есть, бизнес приходит к таким разработчикам с проблемой, а ребята уже не маленькие и много чего понимают в вашем бизнесе, потому что они его автоматизировали, выкатывают вам решение проблемы. Они, как никто другой знают, как решить проблему кратчайшим путем. Разница в том, что задача, которая расписана по пунктам говорит нам о решении проблемы, а не о самой проблеме. Поэтому не нужно расписывать задачу слишком подробно. Главное - указать на проблемы, которые вы видите в этой задаче. А еще и разработчики могут вам указать на проблемы, которые вы не заметили.

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

  1. Предыстория. Тут мы рассказываем о том, откуда задача берется и что из нее следует. Можно просто. Был вечер, ничего не предвещало беды, я решил посмотреть несколько фильмов на нашем сайте. Налил чаю, взял пару печенек, открыл главную, зашел в раздел с фильмами, но тут… При этом форма описания может быть любой. В этом пункте вы даете разработчику контекст того, как вы столкнулись с проблемой.
  2. Суть и описание проблемы/задачи. В этом пункте нужно рассказать о том, как вы столкнулись с проблемой. Например: я зашел в разделы фильмов, увидел в трендах фильм “Люди Х: Апокалипсис” кликнул по нему и нажал на кнопку плей, но тут я увидел то, что плеер не хочет показывать видео и говорит “Can’t find video filename.mp4”. Или же, другой пример по короче : Каждому 7му посетителю - подарок. При этом не забудьте о сроках выполнения.
  3. Цепочка. Или у кого просить помощи/с кем связаться. Если есть люди, которые либо принимают задачу, либо могуть дать ответ на какой-нибудь вопрос, который может возникнуть - опишите это. Например: “Фидбек по этой фиче может дать Ольга, начальник контакт-центра. Потому что фичу кодим именно для них.”
  4. Сроки. Ставить сроки с потолка - бесполезно. У всех есть задачи важнее. У каждой задачи есть свои приоритеты. Чтобы поднять приоритет своей задаче, нужно объяснить ее в задаче. Например: Фичу планируем запускать 1 февраля. Учитывая то. что фидбек от пользователей будем собирать недели 2, то желательно сделать ее к 7 января, чтобы успеть собрать фидбек и обработать его. При этом с приоритетами должны быть согласны и другие отделы.
  5. Мотивация. Вообще - это тема для отдельного поста. Но чаще всего разработчиков мотивируют не деньги и слава, а то, какую пользу он принесет. Поэтому разработчик должен четко понимать, зачем эту фичу делать. Либо это принесет дополнительный доход, либо это облегчит жизнь пользователям.
  6. Варианты решения. Если вы компетентны в этом вопросе (если вы тимлид например), то вы можете предложить свои варианты решения. Но не представляйте его как единственно верное.

Как ставить задачи в первый раз.

Вот вы думаете, прочитали пост и решили, что теперь вы знаете, как ставить задачи. Ставите ее кому-нибудь, а тут вас посылают куда подальше. Это происходит из-за того, что непонята проблема в задаче. Решить это можно легко - поставить задачу вместе с этим человеком.

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

На этом все. В следующем посте я расскажу о том, как делать задачи и не умереть.