Как ставить задачи разработчику. От требований до результата

Хочу обсудить процесс постановки задач разработчику, и их доведение до результата.

Эта тема не так однозначна, как может показаться. С одной стороны, мы все регулярно ставим задачи, и кажется, что в этом нет ничего сложного. Но с другой стороны – каждый делает это по-своему, и нельзя с уверенностью сказать, какой подход единственно верный.

Участники процесса

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

• Заказчик – тот, кому нужна новая функциональность. Иногда эту роль могут брать на себя аналитики или разработчики, если они видят возможность улучшения системы. Но чаще всего в качестве заказчика выступает представитель бизнеса. Он, как правило, лучше всех остальных понимает предметную область, знает особенности компании, но имеет минимальные технические навыки. У него есть отличительная особенность – он отвечает за финансовую сторону вопроса, а это накладывает особые требования на коммуникацию с ним.

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

• Разработчик – ему необязательно вникать в то, зачем бизнесу эта задача, главное – разобраться, что именно требуется реализовать. Однако при наличии технического опыта и понимания сути задачи он может предложить альтернативное решение.

• Архитектор – в отличие от разработчика, ему как раз важно понять, какую потребность бизнеса закрывает эта задача. Это помогает на этапах согласования задачи и анализа выполненной разработки корректно оценить оптимальность подобранного решения.

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

Управленческие вопросы

Первое, что нужно сделать на начальном этапе работы с задачей – выяснить управленческие вопросы.

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

Если важность задачи неоднозначна, выясните, насколько важен конкретный заказчик со стороны клиента. Может оказаться, что «хотелки» именно этого человека (либо целого отдела) клиент оплачивать не готов. И наоборот – руководитель может захотеть какой-то «бантик», и пока он не будет выполнен, откажется оплачивать остальные работы.

Все эти вопросы нужно выяснить еще до начала работы над задачей.

Боль клиента

Следующий важный этап после решения управленческих вопросов – нужно понять боль клиента. Это отправная точка, от которой зависит качество всей дальнейшей работы.

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

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

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

• Одно дело, если мы просто добавим этот флаг и скажем – с вас 10 монет.

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

Бизнес-процесс

Следующий ключевой этап – детальная проработка бизнес-процесса. Именно вокруг него будет строиться техническая работа с задачей, и к нему будут обращаться все участники.

Привязка будущих доработок к бизнес-процессу значительно упростит понимание заказчику. Поэтому при проработке решения обязательно описываем процессы «как есть», и формулируем целевую модель.

Важно проработать бизнес-процесс как можно детальнее – сопоставить шаги процесса с ролями, с используемыми системами, объектами системы. Заказчик должен четко понимать, что изменится в бизнес-процессе: потребуется ли нанимать новых сотрудников или наоборот, потребность в некоторых из них пропадет; добавятся ли какие-то системы или от чего-то можно будет отказаться. Для заказчика это вопрос денег – нужно ли платить больше зарплату либо, наоборот, можно сэкономить на использовании какого-нибудь дорогого софта.

Используемый софт для описания бизнес-процессов зависит от привычек и конечной цели. Visio, Bizagi, Draw.io, Storm, Miro – все эти решения популярны и закрывают базовые потребности.

Но если нам нужна не просто «рисовалка» бизнес-процесса, а полноценное решение с поддержкой ссылочной целостности и возможностью проанализировать, как изменения в системе влияют на связанные процессы, стоит обратить внимание на более продвинутые инструменты – такие, как СППР или Business Studio.

Оформление документа «Функциональные требования»

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

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

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

• Важно, чтобы этот документ был описан на языке пользователя. Поэтому как можно бОльший упор делаем на визуализацию – чтобы заказчику было не скучно читать, и он в принципе понимал, как будет выглядеть система. Если добавляем документы или справочники – рисуем их прототипы, используя MAKER, Balsamiq, конфигуратор, Paint. Если добавляем отчет – для визуализации отлично подойдет Excel.

• Большую роль играет терминология – использование сложных технических формулировок может поставить заказчика в неудобное положение. Например, начальнику отдела продаж будет понятнее фраза «механизм хранения данных», чем «формирование движений» или «регистр накопления остатков». Если документ перегружен специализированными терминами, заказчик будет вынужден либо согласовывать то, что ему не до конца понятно, либо тратить время на уточнения – что критично при сжатых сроках.

Документ «Функциональные требования» оформляется в фирменном стиле заказчика или исполнителя и размещается в общем доступе, чтобы ответственные лица могли централизованно размещать комментарии.

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

Техническое задание. Уточнения в формулировке задачи

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

• На этом этапе нам уже важно описать, какие объекты метаданных мы меняем или добавляем, что является измерением, а что – ресурсом. И здесь важно, чтобы у аналитика были навыки разработки, либо чтобы он работал в паре с разработчиком.

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

• Желательно предусмотреть, чтобы уведомления об ошибке состояли из двух частей: первая – с описанием проблемы; вторая – с рекомендацией по решению. Например: «Скидка не применима к данному клиенту – обратитесь к руководителю», «Не удалось получить данные – попробуйте еще раз, если ошибка повторится, обратитесь в техподдержку».

Напомню самые частые ошибки, которые встречаются на этапе реализации.

• Проблемы с правами доступа. Бывают ситуации, когда выполнили задачу, проверили под админом – все работает. А на проде из-за отсутствия прав на чтение добавленного объекта половина пользователей вообще не могут войти в базу. Это особенно критично в крупных компаниях с большим количеством торговых точек, где упущенная прибыль из-за простоя на исправление ошибки может оказаться значительной. И возникнет вопрос, за чей счет банкет.

• Интеграция с другими системами. Желательно заранее прописать в задаче, какое влияние она может оказать на существующие обмены данных. Например, если мы на стороне УТ добавляем новый вид номенклатуры, то при существующем обмене с 1С:Бухгалтерией окажется, что там для этого вида номенклатуры не настроены счета учета. В этом случае проводки автоматически не сформируются.

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

• Совместимость с оборудованием. А еще – хорошо бы понимать, какое оборудование стоит у конечных пользователей, в особенности – какое разрешение у мониторов. Потому что мы можем сделать красивый АРМ с кучей кнопок и сложной табличной частью, а на практике окажется, что у сотрудников небольшие экраны, и интерфейс будет отображаться со скроллами – информация будет просто не читаема.

Далее фиксируем, кто, когда и какие настройки должен выполнить в системе – запустить обработку, установить константы и т.д.

Важно заранее проработать предполагаемую нагрузку на систему:

• Четко прописать, что эту конкретную обработку мы выполняем после обновления и до входа пользователей в систему.

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

Важно заранее подготовить данные:

• Если требуется установить константы или добавить 2-3 записи в регистр сведений – это несложно сделать вручную по инструкции.

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

Сценарий тестирования

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

Наилучший вариант – сразу добавить в документ «Функциональные требования» описание сценария. Это поможет сформулировать критерии, по которым в дальнейшем совместно с заказчиком будем определять успешность выполненной доработки.

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

Демо

Следующий важный этап – продать выполненную работу заказчику. Здесь важно правильно подать результат: мы можем случайно выставить трудоемкую работу как что-то посредственное или, наоборот, подчеркнуть значимость даже небольшого улучшения.

По опыту, заказчики лучше воспринимают, когда мы не просто демонстрируем новую функциональность, а рассказываем истории:

• В первую очередь стараемся максимально понимающе описать боль клиента, чтобы напомнить ему, от чего мы его исцеляем.

• Потом обращаемся к бизнес-процессам, чтобы напомнить, как плохо было раньше и как прекрасно будет теперь.

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

• При этом следует заранее учесть все технические моменты – чтобы в базе, которую мы показываем, были выполнены все настройки и внесены предварительные данные. И чтобы никому не пришла светлая мысль обновлять ее во время демонстрации.

Инструкции

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

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

Результат зависит не только от исполнителя…

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

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

P.S. Во вложении к докладу вы сможете скачать примеры оформления документов «Функциональные требования» и «Техническое задание». Все данные случайные, все совпадения выдуманные.

Вопросы и ответы

Как бороться с перфекционистом-разработчиком? И нужно ли?

Бороться – это плохое слово. Нужно, чтобы все в синергии работали.

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

Лучше не бороться, а все обсудить с командой.

Какие инструменты использовать для погружения разработчика в бизнес-процесс? Как визуализировать то решение, которое было в голове у РП для разработчика?

Во-первых, когда мы описываем задачу, мы еще и текстом прописываем, кто на этом этапе, что конкретно должен сделать и куда внести.

Кроме этого, можно использовать любые стандартные решения для визуализации бизнес-процессов. Например, в Confluense есть плагин для draw.io, его тоже можно использовать – отрисовать и вставить схемы бизнес-процесса, чтобы их посмотрели.

До какого уровня аналитик должен детализировать задачу для разработчика? Понятно, что это зависит от квалификации разработчика, но нужно ли опускаться до реквизитов? Или это уже задача самого разработчика – придумать объекты, которые он будет использовать, решить, где размещать логику – на клиенте или на сервере и т.д.? Есть ли какие-то формальные признаки для этого?

Если вы говорите про техническую часть, я считаю, что аналитик должен обладать базовыми навыками разработки, это обязательно. В противном случае, он тоже вместе с клиентом может нафантазировать, а потом окажется, что это вообще к 1С не относится, это к веберам нужно идти.

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

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

В том числе, именно аналитик должен задумываться, что больше подойдет для решения задачи – регистр накопления или регистр сведений? Если регистр накопления – то нужно рассчитать, как будут закрываться эти движения. В противном случае разработчик к нему вернется с этими вопросами.

Где в вашем процессе бизнес-аналитик превращается в системного аналитика?

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

У нас в компании роли системных и бизнес-аналитиков совмещены. И я считаю, что при работе с 1С принципиально разделять эти роли сложно, потому что системный аналитик тоже должен понимать бизнес-процессы.

Как аналитик взаимодействует с архитектором, и нужно ли вообще такое взаимодействие?

Мне кажется, это нормальная практика, когда аналитик отправляет описанные задачи на согласование архитектору. До этого аналитик может общаться с разработчиком, чтобы тот помог ему сформулировать задачу, но потом разработчик ждет согласования от архитектора. А аналитик коммуницирует с архитектором напрямую. Каким образом это происходит – уже неважно. Через задачи, через письма, через комментарии на Jira или Confluence.

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

Как вы относитесь к видеоинструкциям для пользователей? Какие программные решения применяете для записи таких инструкций?

Положительно отношусь к видеоинструкциям. Сам неоднократно их делал.

Для записи чаще всего использовал OBS – программу, которая используется для стримов и трансляций. А так есть ocam бесплатный – он позволяет сделать видео быстро, OBS все-таки посложнее.

Еще, как правило, для записанного видео требуется последующая обработка – для этого используется уже сторонний третий софт (Camtasia, Movavi). Там можно со звуком поиграться, вырезать все запинания и убрать лишнее, сократить ролик.

*************

Статья написана по итогам доклада (видео), прочитанного на конференции Анализ & Управление в ИТ-проектах.