Максим Индыков — технический директор IT-компании Примавера и CRM Пачка. Одна из особенностей компании — проектные команды постоянно экспериментируют в области организации рабочих процессов и формируют свои методологии для разработки.
Разработчики — специалисты системные. Это не стереотип, а особенность деятельности и результат профдеформации — им приходится общаться с машиной на её языке, и они невольно перенимают её повадки. Поэтому постановка задачи разработчикам состоит из нескольких последовательных этапов. Эта инструкция может быть полезна не только проектным менеджерам, но и стороне заказчика, чтобы лучше понимать, как разработчики обрабатывают задачи. Причём такой сценарий можно применять как для начала нового большого проекта, так и для доработок уже существующего.
«Клиент интернет-магазина должен иметь возможность оплатить заказ картой онлайн. Для приёма платежей следует использовать банк-эквайринг, выбранный заказчиком».
«При совершении клиентом оплаты необходимо отправлять данные оплаты в ОФД, чтобы клиент получил чек».
Если что-то пойдёт не так, главным аргументом разработчиков будет именно этот документ: «Такого не было в ТЗ».
Для команды разработки важно понять так называемые «корнер-кейсы» — поведение продукта в нестандартных и пограничных условиях. Если готовых ответов нет, надо вместе с исполнителями обговаривать эти моменты и искать подходящие референсы. В нашем примере это могут быть такие вопросы к заказчику или его технической службе:
«Порядок реализации будет такой: художник создаёт дизайн и передаёт его верстальщику. Одновременно с художником разработчики приступают к реализации интеграции с банковской системой. По завершении этих задач разработчики приступают к привязке вёрстки к сайту».
Часто причиной срыва сроков являются не разработчики, а сами менеджеры, которые эти сроки установили. Обычно это происходит так: помимо основной задачи разработчику бесконечно «прилетают» второстепенные на данный момент. Оценка новых проектов, консультирование менеджеров и клиентов, техподдержка уже запущенных процессов — все эти внезапности тратят рабочее время и мешают концентрации, но их нельзя заложить в общую оценку проекта. Их нельзя предсказать, но можно стараться «оберегать» от них разработчика, пока он работает с большой задачей.
Вот основные ответы разработчиков при срыве сроков: «Меня отвлекали на другие задачи» и «Задача была расширена по ходу реализации».
Установка сроков исполнения — это торг между разработчиком и менеджером (заказчиком). Если вы находитесь между, нужно опираться на аргументы обеих сторон, чтобы дедлайн был максимально близок к реальности. К определённому таким методом сроку желательно прибавить ещё процентов 30, и будет в самый раз.
Этот сценарий — не панацея, а шаблон, который может стать стартовой точкой для компании, чтобы в дальнейшем подогнать его под под себя. В зависимости от профессионализма и слаженности коллектива порядок и количество этапов может меняться в сторону увеличения или уменьшения контроля. Важно соблюсти баланс между гибкостью команды и строгостью бизнес-процессов.
Но самое главное: на всех этапах постановки задач разработчикам помните, что их основной ресурс — время. Старайтесь писать в ТЗ по-минимуму, строго по делу и исчерпывающе — словом, цените время — своё и специалиста.
«Примавера» — продуктовая B2B-компания, основанная в Санкт-Петербурге. С 2013 года компания создаёт собственные IT-решения для бизнеса, а также помогает развивать совместные продукты партнёрам, среди которых ПАО «Вымпелком». В портфеле разработчика 6 продуктов, которыми пользуются более 30 тысяч предприятий России и ближайшего зарубежья. «Примавера» является постоянным членом Ассоциации Разработчиков Программных Продуктов «Отечественный софт». С самого основания все сотрудники компании работают полностью удалённо, а в 2018 году разработчик вошёл в рейтинг лучших работодателей в IT по версии пользователей сервиса «Мой круг».
Разработчики — специалисты системные. Это не стереотип, а особенность деятельности и результат профдеформации — им приходится общаться с машиной на её языке, и они невольно перенимают её повадки. Поэтому постановка задачи разработчикам состоит из нескольких последовательных этапов. Эта инструкция может быть полезна не только проектным менеджерам, но и стороне заказчика, чтобы лучше понимать, как разработчики обрабатывают задачи. Причём такой сценарий можно применять как для начала нового большого проекта, так и для доработок уже существующего.
В качестве примера возьмём задачу по доработке платёжной системы для клиентского интернет-магазина по продаже пуховиков. Опишу и основные аргументы исполнителей, чтобы было понятно, чего именно нельзя допустить, ставя задачу разработчикам.
Этап 1. Сбор требований от заказчика
Требования заказчика — это ещё не ТЗ, а то, что его предваряет. Опишите максимально понятно, что конкретно должно получиться в итоге. Задание должно получиться поддерживаемым — это значит, что его несложно переписать с чистого листа, если вдруг, когда ТЗ будет готово, выяснится, что описано совсем не то, что нужно клиенту. В нашем примере описание может содержать такие строчки:«Клиент интернет-магазина должен иметь возможность оплатить заказ картой онлайн. Для приёма платежей следует использовать банк-эквайринг, выбранный заказчиком».
Этап 2. Формирование технического задания
Уточните весь сценарий работы системы. Для этого нужно описать поведение всех экранов и кнопок — даже если вы не разбираетесь в деталях разработки, вы наверняка видели подобные элементы на других сайтах, опишите их как референсы и уточните свои поправки. Не забывайте и про важные для стороны заказчика технические детали реализации. Например:«При совершении клиентом оплаты необходимо отправлять данные оплаты в ОФД, чтобы клиент получил чек».
Если что-то пойдёт не так, главным аргументом разработчиков будет именно этот документ: «Такого не было в ТЗ».
Для команды разработки важно понять так называемые «корнер-кейсы» — поведение продукта в нестандартных и пограничных условиях. Если готовых ответов нет, надо вместе с исполнителями обговаривать эти моменты и искать подходящие референсы. В нашем примере это могут быть такие вопросы к заказчику или его технической службе:
«Как магазин должен обрабатывать ситуации, когда клиент оплатил заказ, но товара не оказалось на складе? Как платежная система должна реагировать на проблемы с интернетом у клиента в момент оплаты?».
Этап 3. Декомпозиция задачи
Даже если разработчик один, разбейте общее задание на подзадачи. Промежуточные результаты нужны, чтобы вовремя проверять как правильность выполнения, так и соблюдение сроков. Нужно понимать, что в случае срыва дедлайнов в ответ на ваш вопрос «Почему?» может прозвучать примерно следующее: «Задача была плохо декомпозирована, при реализации выяснилась её реальная сложность».Этап 4. Распределение задач на разработчиков
Теперь, когда задача декомпозирована, настало время понять порядок выполнения работы, определить зависимости разработчиков друг от друга. Например:«Порядок реализации будет такой: художник создаёт дизайн и передаёт его верстальщику. Одновременно с художником разработчики приступают к реализации интеграции с банковской системой. По завершении этих задач разработчики приступают к привязке вёрстки к сайту».
Здесь, если вы не разбираетесь в тонкостях разработки и даёте задание исполнителям напрямую, придётся проконсультироваться с самими специалистами. Если схалтурить на этом этапе, от разработчиков можно услышать что-то в духе: «Я не мог начать работу, так как был "заблокирован", ждал материалов».
Этап 5. Оценка времени и определение дедлайнов
Поставьте дедлайны для крупных участков разработки и мини-дедлайны для подзадач. Без них любая работа заполнит весь возможный объём времени, а без сроков для подзадач будет сорван и общий дедлайн.Часто причиной срыва сроков являются не разработчики, а сами менеджеры, которые эти сроки установили. Обычно это происходит так: помимо основной задачи разработчику бесконечно «прилетают» второстепенные на данный момент. Оценка новых проектов, консультирование менеджеров и клиентов, техподдержка уже запущенных процессов — все эти внезапности тратят рабочее время и мешают концентрации, но их нельзя заложить в общую оценку проекта. Их нельзя предсказать, но можно стараться «оберегать» от них разработчика, пока он работает с большой задачей.
Вот основные ответы разработчиков при срыве сроков: «Меня отвлекали на другие задачи» и «Задача была расширена по ходу реализации».
Установка сроков исполнения — это торг между разработчиком и менеджером (заказчиком). Если вы находитесь между, нужно опираться на аргументы обеих сторон, чтобы дедлайн был максимально близок к реальности. К определённому таким методом сроку желательно прибавить ещё процентов 30, и будет в самый раз.
Этот сценарий — не панацея, а шаблон, который может стать стартовой точкой для компании, чтобы в дальнейшем подогнать его под под себя. В зависимости от профессионализма и слаженности коллектива порядок и количество этапов может меняться в сторону увеличения или уменьшения контроля. Важно соблюсти баланс между гибкостью команды и строгостью бизнес-процессов.
Но самое главное: на всех этапах постановки задач разработчикам помните, что их основной ресурс — время. Старайтесь писать в ТЗ по-минимуму, строго по делу и исчерпывающе — словом, цените время — своё и специалиста.
«Пачка» —
мобильная CRM-система для малого и среднего бизнеса. Сервис работает по SaaS-модели и объединяет CRM, мессенджер, постановщик задач и канбан-доску. Система поддерживает интеграцию с другими сервисами, а функционал продолжает расширяться.
«Примавера» — продуктовая B2B-компания, основанная в Санкт-Петербурге. С 2013 года компания создаёт собственные IT-решения для бизнеса, а также помогает развивать совместные продукты партнёрам, среди которых ПАО «Вымпелком». В портфеле разработчика 6 продуктов, которыми пользуются более 30 тысяч предприятий России и ближайшего зарубежья. «Примавера» является постоянным членом Ассоциации Разработчиков Программных Продуктов «Отечественный софт». С самого основания все сотрудники компании работают полностью удалённо, а в 2018 году разработчик вошёл в рейтинг лучших работодателей в IT по версии пользователей сервиса «Мой круг».
