Как поставить задачу IT-отделу «для чайников» (часть 2)
В первой части статьи были разобраны базовые принципы постановки задач IT-отделу и чек-листы для сотрудников и Project-менеджеров. Ознакомиться с первой частью можно по ссылке.
Во второй части внимание уделено роли руководителя. IT-эксперт Никита Лебедев-Зиновьев рассматривает отдельный чек-лист для управленцев, который помогает выстраивать работу с IT-отделом более эффективно и снижать количество продуктовых ошибок.
Для руководителя - чек-лист
Для начала пойми, ради чего вообще затевается эта история. Зачем тебе тратить время и силы на постановку задачи? Зачем тебе эта боль?
Ты поставил задачу, декомпозировал её, всё описал, добавил продуктовую логику и уже готов нести в IT-отдел… Но, скорее всего, ты что-то упустил. Нужен ещё один взгляд со стороны.
Если ты видел у других компаний как эта задача реализована:
- Тебе поставили задачу руководство, ты грустный пошел думать как ее решить → сходи к конкурентам, скорее всего, они уже решили этот вопрос и ты сможешь скопировать визуализацию (конечный результат продукта). Прихвати с собой все на созвон с IT-отделом - все, что может доказать то, что это существует и поможет объяснить другим людям:
ссылку на решение конкурентов
видеозапись экрана
скриншоты экрана
формулы
обратная связь от их клиентов (они также видят результат и пользуемся им)
пройди сам путь клиента, запиши это как доказательство, что работает как надо
выпиши что тебе как клиенту НЕ понравилось и чтобы ты хотел исправить и тд.
- Если доказательная база у тебя собрана, то зови на созвон (запись созвона обязательна), начинай объяснять на пальцах, на человеческом языке, как это работает, зачем это. Не пропускай ни единой детали, спрашивай там, где самое важное все ли понятно, нужно 2 раз повторить или нет.
- После созвона попроси посмотреть запись и назначь следующую встречу, где ответственный за задачу или его руководитель расскажет полный путь того, что ты рассказывал. Если человек ничего важного не забыл → ты синхронизировался по продуктовой части, ты молодец.
- Теперь приступаем к написанию продуктового технического задания. Это когда в дело идут Figma-макеты, можно в Miro или на другой доске порисовать. Рисуй так, чтобы было, что обсудить с дизайнером (если присутствует часть визуальная в задаче, к примеру) или же ты хочешь формулы прописать, может ты знаешь как это должно выглядеть у твоих клиентов → рисуй как в последний раз.
- Как только ты все нарисовал, то зовешь на Product-овый созвон программиста главного и кто будет делать, чтобы описать задачу так, как ты понял. После синхронизации дай им время подумать (1-2 дня, зависит от сложности задачи, ответственный сам скажет сколько нужно времени).
- Теперь начинается главная часть:
- Если задача внедряется в готовую систему: программист садится и описывает техническое задание по твоему макету в любом виде (док/файл/figma) → может и вовсе не описывать, зависит от самой задачи.
- Если задача это новый проект, с полноценными нововведениями, то ТЫ сам садишься и описываешь продуктовое ТЗ по собственному макету.
- После этого вне зависимости от задачи у тебя появятся контрольные точки, время реализации и контроль с твоего стороны /отдела контроля по задаче
Если ты НЕ видел у других компаний как эта задача реализована:
- Возьми главного программиста с собой на созвон.
- Как только созвон проведете и ты описал ему суть задачи → договоритесь об итерациях, чтобы протестировать в верную сторону идете или же нет. Итерации позволяют сократить время реализации, где не понятен конечный результат визуально, снижает риск ошибки и говно-кодинга на 1 раз (это когда программист пишет систему так, чтобы ее нельзя было гибко изменить, а полностью подстраивает ее под твои слова)
- 1 итерация должна быть 1-2 недели максимум. В конце ты сам должен понять в верную сторону двигаетесь или же нет, ведь от этого зависят последующие итерации.
- В 1 итерации должность быть только то, что максимально отвечает на вопрос: верный ли курс задан, идем ли к решению проблемы или же нет. Ничего подобного “ на будущее, а давай еще подумаем как потом пользоваться “ не делаем! Только то, что необходимо, ведь вы играете в гонку со временем и вам неведом результат.
Что может быть еще полезно:
- Ваши задачи можно ставить лично на контроль руководителя, если имеется такое разрешение от CEO/руководителя проекта.
- Каждая задача это трата бюджета IT - вам могут отказать, объяснив причину, но если ваша задача не оптимизация вашей работы, а деньги в кассе или же снижение костов, то шанс ее взять возрастает
- Вы не должны контролировать исполнителя → передавайте вашу задачу только через TeamLead, аналитика, Project-manager, если хотите 100% получить обратную связь по ней.
- Если хотите, что бизнес побыстрее дал задачу IT, сядьте и посчитайте что бизнес выиграет взяв в работу именно вашу задачу, ведь это лотерея:
- снижение костов
- оптимизация чей-то работы или всего отдела
- стратегическая задача
- снижение рисков при работе такого-то отдела
- как повысится эффективность отдела после внедрения задачи (KPI/дедлайны/сроки решения чего-либо у отдела) и тд.
- Попросите следовать определенному формату отчетности при сдаче контрольных точек. Мой чек-лист: что хотели, что получили, какие стопперы (ситуация, когда что-то мешает работе), какие подводные камни (части задачи, где программист пока что-то не видит решения)
- Создайте пошаговый чек-лист по приемке полной задачи, я думаю шаблон сами придумаете, чтобы ничего не упустить, он всегда разный, можно использовать из предыдущего пункта часть.
- Замерьте результат который был и который стал благодаря вашей задачи - возможно, вы сделали только хуже и нужно искать причину, а возможно открыли для себя пласт новых задач и увидели буст (супер-решение в моменте для закрытия KPI бизнеса)
Если остались вопросы, то добро пожаловать к нам в Pointpulse на направление Project-manager или напишите в нашу группу в VK .