Пользователь
0,0
рейтинг
2 сентября 2013 в 11:59

Разработка → Жизнь управленца, кадр 4, Планирование — Постановка задачи tutorial

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

Планирование это ключевой аспект работы ИТ менеджера. Люди которые умеют хорошо планировать ценятся на вес золота, их тяжело найти и легко потерять :). Давайте я опишу собственные принципы и методы планирования, которые я применял в своих компаниях.



1. Фиксируйте все задачи



Обязательно фиксируйте задачи. Разработайте инструкции для ваших продакт, проджект и иных менеджеров и обязательно фиксируйте все задачи, которые должны быть выполнены разработчиками. Когда мы проводим разбор полетов, в случае наступления конфликта между коммерческим и отделом разработчиков, мы используем этот принцип первым. Нет зафиксированной в Жире, в нашем случае, задачи, виноват тот, кому нужно выполнение данной задачи.

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

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

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

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

В целом ключевой принцип планирования, то, на чем основывается весь процесс планирования — «Все задачи должны быть зафиксированы в информационной системе, задачи вне информационной системы не существуют для специалиста (разработчик, админ и тд).

2. Правильно формулируйте задачи.



Итак, задача должна быть зафиксирована. Мы это поняли. Теперь важный момент задача должна быть зафиксирована правильно. Задача, задаче рознь. Скажем я могу написать задачу для существующей системы типа „сделайте админку красиво“, и сказать что я ее поставил и теперь выполняйте. В принципе это возможно, но мы предлагаем для постановщиков задач следовать простому принципу, для которого не нужно иметь какое то специальное образование. Это принцип SMART.

Я очень люблю привычку американцев делать запоминающиеся вещи в виде отдельных слов, так их легко запомнить и легко применять. Помните, в разделе коммуникации мы говорили о правиле ретроспектив ОК. Обсуждение и Контроль. Так вот, SMART описывает то, какой должна быть задача, умной, smart — по английски умный.

S — Specific. Задача должна быть специфичной, точной, конкретной. Скажем сделать админку красиво, не подходит под этот критерий.

И задачу можно эволюционировать до „Хочу чтобы в админке я мог сам строить отчеты, чтобы считались нужные мне формулы и я мог все это сохранять в Эксель.

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

Тут наша задача опять эволюционирует. До “Хочу чтобы в коммерческих отчетах в админке я мог за два-три клика мыши оформить отчет за месяц, при этом срок загрузки отчета был не дольше 3х секунд, я хочу иметь в возможность группировать и фильтровать по каждой колонке, с отработкой формул для колонок типа Дата, Сумма, Дилер».

A — Achievable. Задача должна быть достижимой. Важно понимать, что у задачи должен быть тот объем и параметры, которые можно выдержать. Скажем, если вы знаете что некоторые отчеты не могут загружаться в пределах 3-х секунд, вы должны заранее, отказаться от принятия такой задачи, на уровне еще ее обсуждения. Если задачу нельзя выполнить, не берите ее. Очень часто, мы слышим фразы, война план покажет. Не покажет, если вы выбрали задачу которую нельзя достичь, вы сразу испортили проект. Плохое настроение будет у вас, у заказчика, у сотрудников. Поэтому обязательно научите ваших заказчиков консультироваться с вами на момент постановке задачи, а можно ли ее достичь в текущих условиях.

Тут наша задача эволюционирует до «Хочу чтобы в коммерческих отчетах в админке я мог за два-три клика мыши оформить отчет за месяц, при этом срок загрузки отчета был не дольше 3х секунд, я хочу иметь в возможность группировать и фильтровать по каждой колонке, с отработкой формул для колонок типа Дата, Сумма, Дилер. При этом Общий отчет по агентам может иметь время загрузки до 10 секунд по данным за 1 месяц.»

R — Result oriented. Задача должна быть нужной. Не для галочки, а реально нужной. Задача должна ставиться, чтобы получить результат, который будет нужен Заказчику. Заказчик должен ориентироваться на то, какая польза будет от задачи, и он должен знать что тут он должен консультироваться с вами. Вы посмотрели задачу, которую он хочет поставить и решили ее немного изменить.

В рамках этого критерия заказчик проставляет важность задачи для него.

«Хочу чтобы в коммерческих отчетах в веб интерфейсе и админке я мог за два-три клика мыши оформить отчет за месяц, при этом срок загрузки отчета был не дольше 3х секунд, я хочу иметь в возможность группировать и фильтровать по каждой колонке, с отработкой формул для колонок типа Дата, Сумма, Дилер. При этом Общий отчет по агентам может иметь время загрузки до 10 секунд по данным за 1 месяц. Важность этой задачи 8 по 10 бальной шкале, где 1-не важно, а 10-очень важно»

T — Time oriented. Задача должна иметь сроки выполнения, потому что любая задача ценна только в определенное время. И тут мы подходим к главному моменту, Заказчик обязательно должен проставить реалистично когда ему нужна эта задача. И вы, на основании Важности задачи и ее ожидаемого Срока сможете ее запланировать.

Наша задача эволюционировала до:

«В течение месяца с момента постановки задачи, хочу чтобы в коммерческих отчетах в веб интерфейсе и админке я мог за два-три клика мыши оформить отчет за месяц, при этом срок загрузки отчета был не дольше 3х секунд, я хочу иметь в возможность группировать и фильтровать по каждой колонке, с отработкой формул для колонок типа Дата, Сумма, Дилер. При этом Общий отчет по агентам может иметь время загрузки до 10 секунд по данным за 1 месяц. Важность этой задачи 8 по 10 бальной шкале, где 1-не важно, а 10-очень важно»

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

Если вы научите Заказчика ставить SMART задачи, то вы сможете значительно снизить нагрузку на свой отдел разработчиков, когда вы начнете Разбирать задачи, о чем мы поговорим в Планировании 2.

Предыдущие статьи:

Жизнь управленца, кадр 1, не надейтесь на понимание
Жизнь управленца, кадр 2, жесткая воля
Жизнь управленца, кадр 3, коммуникации
Павел Пронин @undry
карма
0,0
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое Разработка

Комментарии (22)

  • +1
    А можно ссылки на предыдущие статьи вставить в статью, чтобы людям не приходилось лазить в список постов автора?
    • +1
      Исправил
      • +1
        Добавьте такое же содержание к предыдущим статьям и вообще молодцом будете!
        • 0
          Готово.
      • 0
        Спасибо!
  • +1
    Котелок, не вари, пожалуйста. Ваши методы направлены на выжимание людей и на конвейер, а также на самопиар, но не рассказывают ничего нового и интересного для любого руководителя, побывшего в бизнесе отрасли хотя бы год-два.

    Действительно хороших спецов вы такой риторикой и методами не заманите, а обычные итак к вам придут.
    • –3
      Iago я всегда отношусь с вниманием к критике. Если вам не интересно, то вы можете не читать. Есть люди которым это может быть интересно. И я уверен что для руководителей побывавших в этой отрасли и 5 и 10 лет найдется много интересного.

      У меня работают лучшие в своей отрасли специалисты, мне нравится с ними работать. Мы создаем продукты, которые востребованы. Так что удачи Вам в Ваших невероятно интересных и открывающих глаза на мир статьях.
      • 0
        Вы определитесь сначала — создаете продукты или занимаетесь аутсорсингом. Если, как я понимаю, второе, то вы выполняете подряд на хорошо если 15% от разработки продукта, и делаете его не себе — все, что вы получаете после окончательной оплаты, это возможность улучшить свое портфолио за счет хорошего продукта ваших заказчиков.
        • 0
          Есть компания которая занимается аутсорсингом. Только модель немного другая, мы вначале создаем продукт под заказ, затем его сопровождаем.
          • 0
            Это вообще стандартная схема аутсорсинга — завязать отношения с большим заказчиком и сопровождать его большие продукты. Лучших заказчиков с точки зрения хеда компании и не найти.

            В общем называйте это тогда обыкновенной заказной разработкой. Хотя мне симпатична ваша уверенность в себе и энергетика — пока иные будут долго думать, по 300 раз взвешивая все за и против, вы действуете. В заказной разработке так и надо, только не преподносите это как рай для девелопера.
            • 0
              Я ни в коем случае не называю это раем для деволопера. И для меня это не рай. Это сложная, долгая и требовательная работа. У нас не гугл к сожалению и нет бюджетов на большие офисы, просторные комнаты, бесплатную еду. Такой офис я видел в компании Digi в Малайзии.

              У нас скорее «немецкий» офис, много работы, сложной. Достойная ЗП, все знают куда расти, если у людей есть возможность уехать развиваться за границу мы их только поддерживаем. Наши сотрудники есть в Гугл, Майкрософт, в крупных компаниях по безопасности.
  • 0
    Форма выставления задач в формате SMART является распространенной, но не очень любимой. Амбициозные люди зачастую выставляют себе заоблачные цели (критерии выполнения), и в результате не достигают их, что приводит к разочарованию. А ленивым не нравится излишняя формальность и требовательность, которая не позволяет скрыть недоработки. Вот и работают по такой методике средний класс сотрудников большинства компаний. А таких сотрудников в российских компаниях, как в принципе и в обществе, очень мало.
    • 0
      Я бы только сказал, что чем больше бюрократии, тем все же больше способов скрыть недоработки. Бывало, слушал такие диалоги:

      — У нас архитектура гниет, каждое новое изменение нужно протаскивать через 10 конфигов и 2 синглтона, тут спагетти, там костыли…
      — Ну вот подожди, мы же работаем по аджайлу, велосити нормальное, эстимэйт совпадает более-менее с реалом…
      — Да что эстимэйт, у нас же в коде черт не валялся — один фикс на три новых бага.
      — Подожди, в последнем отчете был замечен рост велосити, фидбэк по команде нормальный, все ок, работай в удовольствие.
      — Ну вот смотри на пальцах, мне надо сделать эту фичу, она размазывается на 3 модуля, хотя должна быть только в одном, это как?
      — Ну хорошо, заэстимируй себе на 10% больше времени на рефакторинг, я понимаю. тебе нужно развиваться…

      Очень печально выходит. А олухов и недальновидных программистов такое положение дел вполне устраивает, и начальство довольно.
      • +1
        Шикарный диалог.
        Можно добавить, что всё это является частью рисёча, проводимого в коворкинге, попивая смузи.
        • +2
          Собственно, дискашн наших кейсов был забукан в митинг-руме.
          • +1
            Тру.
      • 0
        Абсолютно не устраивает. Любой код обязательно рефакторится, и на ретроспективе код обсуждается публично если замечены признаки говнеца. Отдел тестирования знает достаточно чтобы делать не только манки тесты. И если код плохой то наш коуч может надавать по ручкам разработчикам, которые его сварили.

        Коучем для молодежи является опытный разработчик. Тех кто за три месяца не учится писать нормальный код — увольняем.
        • 0
          Хотелось бы верить, что это так, но зачастую при заказной разработке все идет по воле заказчика. Если он, или его человек, понимает что нужен рефакторинг (сам пишет код) — будет рефакторинг, если не понимает — не будет рефакторинга, будут обещания что вот в конце этой итерации, вот-вот все баги дофиксим и будет.
          • 0
            Все зависит от того как вы выстроили отношения с Заказчиком. Если он один единственный и все яйца в одной корзине — тогда опасно. Если нет, то сила на вашей стороне, как и код.
            • 0
              Да ладно, я много лет работал в сервисе. У компании были десятки заказчиков с разного размера проектами, и никто никогда не отказывался от заказчиков, которые платят. Если заказчик платит, и контракт составлен выгодный компании — он что хочет, то и делает, и всем пофиг на качество кода на проекте, оунеру компании-аутсорсера в первую очередь.
              • 0
                Плохой код приводит к увеличению стоимости поддержки проекта. Но я согласен, что если плохой код работает, то это неплохо. И смотря что считать говнокодом. Если он влияет на работоспособность системы это одно, а если не удобно читать, или структурировано не очень — другое. Если будет стоять выбор сдать проект или вылизать весь код, я выберу сдать проект.

                Тут вы конечно правы. Но если вы айти директор в компании, а ваша компания аутсорсер, то можно совместить приятное, с полезным. Редко, но можно.
                • 0
                  Хотелось бы верить. Вообще, для аутсорс-компаний дорогая поддержка выгодна :)

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.