Как поставить задачу IT-отделу “для чайников”

IT-отдел в каждом бизнесе на 2026 год является ключевым. Если сотрудник начинает взаимодействовать с “IT-отделом”, он может не понять с чего начать диалог и как объяснить в чем проблема, почему он пришел.
IT-отдел в каждом бизнесе на 2026 год является ключевым. Если сотрудник начинает взаимодействовать с “IT-отделом”, он может не понять с чего начать диалог и как объяснить в чем проблема, почему он пришел.

В этой статье IT-эксперт Никита Лебедев-Зиновьев делится практическими подходами к постановке задач в IT-среде. Материал основан на реальном опыте работы с продуктами, командами разработки и бизнес-заказчиками.

Эта статья должна помочь найти ответы на все ваши вопросы. В статье описаны общие знания для Project, можно пользоваться как настольной книгой при постановке задачи. Результатом прочтения будет - снижение минимум в 2 раза частоты переносов и длительных итераций в продуктовых IT-задачах.

Суть проблемы.

Когда вы ставите задачу IT-отделу, можете опираться на эти чек-листы (они помогали мне 8 лет назад, когда я впервые вошел в эту сферу)

Если вы являетесь руководителем, то для вас есть отдельный чек-лист руководителя о котором мы расскажем в следующей статье.

Руководитель - это когда в наличии минимум двое подчиненных, забравшие половину вашей головной боли. Вы должны объяснять как делать задачи, хотя бы на процентов 20 (зависит от уровня ваших подчиненных, конечно же).

Если вы просто ставите задачи тем, кто ниже вас → вы скидываете ответственность.

Для всех:

  • Если вы являетесь менеджером среднего звена, то читайте все, что есть в этом документе.
  • Каждая поставленная задача это только 10% успеха. 60% успеха - четко описанное ТЗ, 20% это синхронизация/контрольные точки/точки приемки задач, а оставшиеся 10% это контроль.
  • Существует лишь 1% компаний в мире, которые могут позволить себе НЕ писать технического задание для своих специалистов разного звена - кладбище стартапов в Калифорнии.
  • Каждый раз, когда вы придумали “гениальную идею”, скорее всего кто-то ее уже реализовал. Гениальные идеи приходят после проделанного труда, после результатов в реальном времени, а не “озарение в момент ретроградного Меркурия”

Для менеджера среднего звена:

Предисловие

  1. Представим себе ситуацию - вам поставили задачу, например, “оптимизировать вашу работу с помощью telegram-бота”. Сядьте, спокойно, отдышитесь, запейте чаем и приступайте к написанию наброска. Набросок - выписывайте все то на что у вас уходит больше 20% времени в ваш рабочий день. Это могут быть звонки, могут быть совещания, могут быть расчет чего-либо в excel-таблице ⇒ миллион возможных вариантов. Расписав все это, превратите в строки и поставьте рядом то, на что больше всего вы НЕ хотите тратить время, потому что это рутина, “обезьянья работа” и тд.
  2. Поздравляю! Вы только что ДЕКОМПОЗИРОВАЛИ проблему → вы разбили ее на сущности, выписали тезисно каждую драгоценную минуту вашего времени, теперь вы готовы еще раз подумать, и вот о чем: любой специалист работает так, как описано в регламенте и с тем, что уже придумал тот же мозг человека.
  3. Если вы хотите попросить специалиста оптимизировать какой-то пункт из того списка, вы должны поискать закономерность (это когда действия повторяются с ТАКИМ ЖЕ исходом из раз в раз и далее до бесконечности). Например, мне прислали готовый excel файл из отдела финансов, чтобы я загрузил этот файл в 1C в расчетный лист и далее скачала его с подписью уже. Каждый раз вы получаете готовый расчетный лист с подписью и из раза в раз вы тратите 20 минут своего времени, потому что 1С долго делает расчет по простой формуле из excel и подпись через Photoshop вставить можно.. Отлично, вы нашли закономерность - вы ставите галочку в подготовленном списке напротив данной проблемы. Как только пройдетесь по всему списку и найдете еще галочки, то после этого вы идете к вашему руководителю, чтобы посоветоваться хорошее ли решение или еще можно поискать. Если руководитель дает добро, вы идете к чек-листу ниже.
  4. Честно, скорее всего после декомпозиции вы поймете, что все лишние задачи в вашем рабочем дне это время на попиздеть с коллегами, чаек/кофе, выйти сигу выкурить и тд., но представим ситуацию - вы реально работаете 24 часов/7 дней в неделю и знаете что и как оптимизировать.

Чек-лист

  • Сформулируйте проблему на человеческом языке и опишите полный цикл ваших действий, хоть на бумаге, хоть на словах
  • Подумайте как бы вы хотели видеть в конце результат:

“моя работа полностью зависит от IT-решения” - не подходит

”эта задача сэкономила мне 20 минут времени и честно пойду к коллеге потрещать за чашкой кофе” - подходит, но можно лучше, IT-отделу, если честно, без разницы на вас

”я получил 20 минут свободного времени, первое время я перепроверю работу IT-решения и если все правильно работает, посмотрю что еще можно оптимизировать из списка” - ты прекрасный сотрудник

  • Спросите мнение программиста и если у него нет вопросов, обязательно спросите: объясни, пожалуйста, как ты меня понял. Человек говорит с вами на одном языке, но думают ВСЕ по-разному. Нужно синхронизироваться.
  • Спросите про сроки реализации полные и про то, какие контрольные точки он видит по задаче - таким образом вы не оставляете его одного, а участвуете в создании, максимально синхронизируясь. Да, возможно, вы будете общаться с Project-ом или Teamlead-ом, но разницы нет особой в должностях → вам нужно быть рядом. Возможно, вам придется долбить не самого программиста (исполнителя), а его руководителя, но разницы реально нет, спрос единый, ответственный для тебя либо руководитель, либо исполнитель.
  • Опишите контрольные точки так, чтобы понятно вам и ему следующее: что будет сделано в этот промежуток времени и что ты увидишь в момент приемки задачи. Вы еше раз декомпозируете задачу, но так, чтобы вы собирали пазл из готовых частей, а не из говна и палок.
  • Еще раз синхронизируйтесь по контрольным точкам и как только будет полное понимание - отпускайте программиста. Никогда не придумывайте варианты реализации за него, никогда не пытайтесь понять ход его мысли, даже если вам кажется это по-человечески. У вас своя работа, у него своя. Вы описали, что ему делать, поставили точки контроля и уходите, не надо нянчится с вами.
  • После этого у вас появляются несколько контрольных точек и самое важное 2 срока - технический, который дал вам программист для тестирования полной конструкции и продуктовый, который программист назвал “сделаю за 3 дня, ох*ешь как круто получится.” Самое важное тут добавить к сроку программиста когда будет говорить дедлайн руководителю (если ты с программистом раньше не работал и не знаешь его реальные сроки) примерно 20-30% времени. Если специалист сильный, вероятность, что он ошибется низкая, согласен. Но скорее всего это будет базовый middle, который старается тебе понравится и чтобы ты быстрее увидел то, зачем пришел → угодить тебе хочет.

Я слышал уже на 5 языках - извини, думал, что успею уложиться в дедлайн. Завтра точно будет на продакшене, жопу ставлю. Жопу после так никто и не видел...

  • Проходя контрольные точки ты видишь реализацию, проверяешь все ли сделано так, как ты просил или же нет. Вот тут и появляется настоящая картина происходящего - любые ошибки это “пару часов работы”, которые превращаются в пару дней работы.. По сути, ты следишь за работой конвейерной ленты где движутся части твоего будущего IT-решения. Как только видишь проблему не отпускай программиста, жди решения и не переходи к следующей контрольной точке.
  • После того как все части соединяться, возьми 2-3 дня на тестирование продукта, потыкай его, посмотри как работает, попробуй “сломать его”.
  • Если все работает, то проси выкладывать на stage или production (че есть, то и проси, тебе главный IT скажет что в данной ситуации уместно).
  • Бери время на 2-3 дня также проверки полной работоспособности продукта и если все устраивает - скажи спасибо программисту, он молодец.
  • Выпиши все моменты, которые тебе не понравятся и обсуди лично с программистом почему возникли моменты десинхронизации, почему сроки сорвались, почему ты не сразу получил то, что хотел и тд. Если человек толковый, то сразу расскажет почему и как (проси всегда на человеческом → если часто слышит отмазки, мол задач много, забыл, упустил, то сразу руководителю скажи, что человек филонит → всем будет лучше).
  • Также выпиши за какое время сделана задача, сделана ли в срок, можно было бы ее ускорить с твоей стороны (возможно, не до конца продумал суть проблемы и тебе подсказывали во время реализации). Аналитика поможет только для твоего личного роста, если снова придёшь в IT-отдел.

Если остались вопросы, то добро пожаловать к нам в Pointpulse, на направление Project-manager или напишите в нашу группу в VK

12
2
1
Начать дискуссию