Всем добрый день. В своих предыдущих постах я говорил о воле, лидерстве и коммуникациях, тех моментах что, по моему мнению, являются ключевыми для управления ИТ компанией. Теперь, я бы хотел поговорить о самом важном моменте в жизни любой ИТ компании — планировании.
Планирование это ключевой аспект работы ИТ менеджера. Люди которые умеют хорошо планировать ценятся на вес золота, их тяжело найти и легко потерять :). Давайте я опишу собственные принципы и методы планирования, которые я применял в своих компаниях.
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.
Автор: undry
