Есть поговорка: «Сделай так, я не знаю как, и принеси мне то, я не знаю что», и обычно, по иронии судьбы, это описывает плохо поставленную задачу – то, что мы все слишком хорошо знаем и с чем приходилось сталкиваться не один раз многим командам.
Ловушки неправильно поставленных задач
Коммуникация внутри любой команды – одна из ее сильнейших опор. Результаты совместных усилий членов команды зависят от того, насколько хорошо они могут обсуждать части процесса, идеи и предложения. Но самое главное — это то, как излагаются начальные задачи. Четкие, прозрачные задачи легче понять, а это значит, что команда может начать работать раньше и не тратить много времени на то, чтобы задавать уйму вопросов, в процессе. Кроме того, если каждый понимает, в чем заключается его роль и какую часть продукта они разрабатывают, будет легче собрать эти части вместе, когда придет время
Если вы думаете о команде разработчиков как о драгоценных часах, каждый член – ценная часть. Чтобы часы функционировали должным образом, все части должны быть на своих местах, выполняя свои функции. С людьми немного сложнее, но принцип тот же. А общение — это то, что помогает смазывать шестерёнки человеческого механизма. Если вы правильно ставите задачи, если говорите четко и логично, ваши часы, я имею в виду, ваша команда будет служить вам хорошо и преданно на долгие годы.
На самом деле недопонимание при постановке задач – гораздо большая проблема, чем все думают.
Причины и последствия недопонимания
К сожалению, есть деловые люди, владельцы продуктов или бизнес-аналитики, которые пишут задачи для команд разработчиков и даже не знают, что у них проблемы с коммуникацией. Даже опытные бизнесмены иногда становятся жертвами бюрократии и расширенной иерархии. Иногда владельцы продуктов просто не играют в полной мере свою роль. Владельцы продуктов должны быть связующим звеном между бизнесом и командой разработчиков. Их основная задача – хранить все функции, запрашиваемые бизнесом, в одном месте и доводить до разработчиков требования к продукту. Однако это не всегда происходит так, как должно.
В этом случае возможны два сценария. Либо владелец продукта даже не знает о проблемах при передаче задач, либо этот сложный процесс является обычным способом ведения бизнеса.
Однако всем нам приходится сталкиваться с тем фактом, что неверно сформулированные цели могут привести к стрессу и напряжению в команде разработчиков, в то время как неправильно или нерационально поставленные задачи часто требуют дополнительных усилий (и денег) для выполнения. Что приводит к превышению бюджета и нарушению сроков (что также может привести к штрафам). И, конечно же, мы тратим много времени на объяснение требований снова и снова.
Давайте внимательнее посмотрим, что происходит. Каковы основные проблемы, которые могут вызвать недопонимание между командой разработчиков и клиентом? Большинство из них можно условно разделить на три типа:
- Команда не совсем понимает бизнес сферу клиента
- Иногда деловой язык и технический язык сильно отличаются
- Задачи недостаточно описаны и имеют важные пробелы
После того, как мы определили эти три направления, становится легче понять, что именно могут сделать клиенты, чтобы лучше ставить задачи командам разработчиков, с которыми они работают, экономя время, деньги и энергию. Самое главное, помните, что там, где есть проблема, всегда есть решение.
Как правильно ставить задачи
Итак, что делать, если команда разработчиков не знает тонкостей предметной области, с которой им приходится работать?
- Особенности бизнеса
- Бизнес ожидания
- Проблема + решение
- Крайний срок
Сделать презентацию проекта
Прежде чем приступить к разработке, начните сотрудничество с презентации набора функций будущего продукта. Подробно опишите, какую проблему он собирается решить, а также свои бизнес-ожидания. Приведите примеры конкурентов и установите сроки, если таковые имеются. Это могут быть обещанные заинтересованным сторонам или связанные с тематической выставкой. *
* Например, если через шесть месяцев будет выставка стартапов, в которой вы определенно хотите принять участие, сообщите об этом разработчикам и заранее определите масштаб для команды разработчиков, чтобы у них было достаточно времени для работы.
Имея эту информацию, команда разработчиков может начать эффективную работу над архитектурными решениями уже на ранних этапах, что может помочь им понять, сколько времени это займет и какие подходы им следует использовать, а также увидеть ценность их работы для бизнеса.
Предоставьте дорожную карту бизнесу
Это поможет определить более разумный и согласованный подход к развитию. Что наиболее важно, это поможет разработчикам понять порядок, в котором все функции должны быть реализованы, как все они работают вместе и каковы их зависимости – будь то друг от друга, параллельное выполнение или важные контракты. *
* Если вы работаете на что-нибудь , что требует интеграции с банком , или платежной системы, например, иметь в виду , что банки довольно бюрократичны, так что не стоит рассчитывать на подписание всех необходимых договоров быстро. А если вы работаете над комплексным решением по банковскому обслуживанию, оформление документов может существенно повлиять на сроки.
Найдите общий язык
Деловой язык и технический язык различны. Что вы можете сделать, сотрудничая с командой разработчиков, чтобы это не испортило ваше общение?
Независимо от того, насколько хороши разработчики в своей области, им может быть сложно понять некоторые требования клиента. Особенно, если они используют узкоспециализированную терминологию из области, в которой будет использоваться продукт. Как клиент компании-разработчика или владелец продукта, работающий с ней, вы должны помнить об этом и сохранять простоту. Задания должны быть написаны понятным для всех языком. Или, если вы чувствуете, что таких терминов нет, обе стороны должны оговорить и согласовать, какой словарный запас вы собираетесь использовать во время проекта.
Если после всего этого остаются неясные вопросы, команда разработчиков может отправить свои запросы клиенту. Важно, чтобы они были четко сформулированы и профессиональны, а также использовали деловые термины и фразы, такие как «Правильно ли я / мы это поняли, что…» или «… быть на одной странице». Ни при каких обстоятельствах клиент не должен чувствовать себя неполноценным из-за непонимания технического термина. Но если обе стороны найдут понимание, а команда разработчиков полностью понимает бизнес-потребности клиента, они могут даже предложить лучший подход к их удовлетворению. Однако этого можно достичь только в условиях открытого и доверительного общения.
Типы задач, которые следует помнить для эффективной постановки
Структурированная задача, сфокусированная на самом важном, такую задачу легче понять и реализовать. Вот почему, я думаю, команде важно заранее определиться с типами и содержанием задач, над которыми они будут работать.
На мой взгляд, есть три типа задач: разработка новых функций, исправление ошибок и исследования. Все они имеют свои отличительные особенности. Чтобы поддерживать хорошую структуру задач, сосредоточьтесь на них и на том, что действительно важно.
Существует множество подходов к формулировке задач, но их общая цель – подробно описать функции и предоставить ценную информацию. Обычно они состоят из:
· Заголовок – краткое описание задачи, отвечающее на вопросы – Что? Где? Когда?
· Описание – суть задачи и реальный набор целей, которые необходимо достичь.
· Бонус! – дополнения, помогающие разобраться в описании:
o Скриншот с пометками о задаче
o Зависимости и эффекты от других частей приложения
o Файл с сохраненными формулами (если это расчет)
o Интерактивный прототип, показывающий, как перемещаться между страницами.
o Ссылка на конкурента
Если вам нужно сообщить об ошибке, для этих задач потребуется немного другая информация. Вы должны четко указать, что пошло не так, где, когда и при каких обстоятельствах. Чтобы он оставался ясным и прозрачным, используйте эти части:
· Заголовок – эта часть такая же, как и в пункте (а) – в краткой форме вы говорите, что произошло, где и когда.
· Описание. Помимо шагов по воспроизведению, идеальное описание содержит
o Пользовательские данные о том, кто столкнулся с ошибкой, и среда, в которой возникла ошибка;
o Время возникновения ошибки;
o Дополнительные условия, характерные для данного конкретного применения;
o Ожидаемый и фактический результат;
o Не соответствия исходным требованиям, скриншотам и т. д.
Не все клиенты осознают важность хорошо написанного отчета об ошибке. Следовательно, они не тратят время на то, чтобы записать шаги воспроизведения. Иногда они просто не понимают ценность подробной задачи, но все же хотят исправить и делают всё для того, чтобы исправить ошибку как можно скорее. Однако это приводит к обратному — недостаточно описанная ошибка, влечет за собой не ожидаемый результат, что приводит в свою очередь к повторному изучению, воспроизведению и только потом к окончательному.
Есть еще одна проблема, которая может возникнуть, когда клиенты не осознают важность контекста или точного местоположения ошибки. Например клиенты могут сообщить о проблемной кнопке, просто отправив снимок экрана кнопки, но не всего экрана с указанием URL-адреса, времени на экране компьютера и т. д. Эти данные могут существенно увеличить время исправления. Чтобы сэкономить время всем.
Общие рекомендации и советы по постановке задач
Как и многое в жизни, крошечные детали могут иметь большое значение. Точно так же есть функции, которые помогут сделать задачу понятнее для всех и сохранят весь процесс разработки прозрачным и в хорошем состоянии.
Исполнитель – лицо, которому поручена задача и который отвечает за ее выполнение. Кто-то к кому клиент может обратиться с вопросами, касающимися этой конкретной части процесса.
Приоритет – оптимизация процесса разработки за счет установки приоритета задач и минимизации ненужного общения. Клиенты должны решить, какая функция и какая задача для них важнее в данный момент.
Срок выполнения – конечно, команда должна знать временные рамки, назначенные для задачи, особенно если она не была решена или согласована заранее.
Чтобы помочь всем участникам видеть, где они находятся в любой момент времени, важно включать обновления статуса каждой задачи. Я рекомендую единое описание статуса – три фазы, которые при необходимости можно разделить на подэтапы. Это поможет сохранить прозрачность и даст общее представление о том, что происходит:
Этап 1. Разработка бизнес-требований.
Этап 2. Процесс разработки.
Этап 3. Принято клиентом и развернуто.
Когда вы начинаете проект, вам нужна информация о продукте. Как только все требования выполнены, задача готова к разработке. Далее непосредственно разработка, после переходим к проверке задачи. После тестирования задача либо выполнена и готова к развертыванию, либо повторно открывается для улучшения и только после завершения помечается как готовая к развертыванию.
Резюме
Все это доказывает, что любой проект требует структурированного общения и четкого понимания между заказчиком и реализацией, владельцем проекта и продавцом. Плохо объясненные задачи и неопределенно сформулированные требования могут затормозить любой проект, существенно задерживая развертывание продукта и значительно увеличивая затраты на разработку.
Чтобы избежать любого возможного недопонимания, обе стороны должны знать, какие болевые точки могут возникнуть в будущем, и заранее обсудить их. Выбрав словарь, который будет использоваться в проекте, вы сможете прояснить любые термины, которые могут вызвать проблемы. Наконец, очень важно обсудить сроки и другие возможные ограничения. Помимо всего этого, должна быть обсуждена эффективная структура задач, а также способ сообщения об ошибках в приложении. Это может показаться ничем, но, в конце концов, это то, что сделает работу как для клиента, так и для команды разработчиков максимально гладкой.
