Как писать постановки на разработку

Как правильно поставить задачу для разработки

«Эти разработчики опять ничего не поняли!» — возмущается заказчик мобильного приложения. Но мы все знаем, что у разработчиков тонкая душевная организация и куча злых мемов на случай недопонимания с заказчиком. Чтобы не попасть в череду уточнений, согласований и — самое плохое — исправлений ошибок, нужно просто грамотно написать задачу для специалистов. Как это сделать, рассказывает руководитель проектного офиса “CleverPumpkin” Лада Ларкина.

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

Этап подготовки

Главное: вы сами должны четко представлять ожидаемый от разработчика результат — без этого не получится правильно описать задачи.
Отнеситесь к сбору информации ответственно: до того, как задача попадет к разработчику, вы должны сами полностью понять бизнес- и функциональные требования.
Главное требование к задаче – прочитавший её разработчик должен сразу понять, что ему нужно делать, и это представление должно совпадать с ожиданиями менеджера. А после прочтения идеально описанной задачи у разработчика появляется четкое представление, как он будет ее выполнять.

Декомпозиция задач

Проанализируйте, как задача может быть декомпозирована. Разделить большую задачу нужно так, чтобы между задачами не было пересечений и они логично дополняли друг друга. Возможно, декомпозированную задачу предстоит выполнять разным разработчикам, и важно, чтобы они не делали двойную работу, минимально пересекались и по итогам реализации было минимум конфликтов.
Если в прогрессе декомпозиции появилось несколько задач, которые нельзя делать последовательно — значит, вы перестарались. Разделять задачу нужно, если ее части можно делать одну за другой.
Но базовое правило для декомпозиции — длительность работы над одной задачей не должна быть больше одного дня. В редких случаях — больше, например, если это сложная интеграция, которую не разбить на несколько шагов. Хотя и тут речь может идти о подзадачах не функциональных, а технических.

Название задачи

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

[версионная особенность] [раздел] — [часть экрана] — [что сделать]

Разберем каждую часть названия:

• [версионная особенность] — это может быть версия платформы, MacOS/iPad фичи;
• [раздел] — описывает, в каком разделе добавляется функциональность;
• [часть экрана] — указывает конкретный блок на экране, если изменения касаются его;
• [что сделать] — суть изменения или фичи;

Примеры хороших названий:

• «Подключить Firebase Performance»
• «Профиль (авторизованный) — добавить пункт история заказов»
• «История заказов — реализовать загрузку и отображение списка заказов»
• «Заказ из истории — Блок итого — Добавить строку дополнительных услуг»
• «[iPad] История заказов — Реализовать просмотр конкретного заказа в split view режиме»
• «[iOS 13+] Настройки — Добавить пункт «Siri shortcuts»

Примеры неудачных названий:

• «Подключить экран к API» — (какой раздел, экран?)
• «Цветовая индикация» — (ее нужно добавить? изменить? где находится?)

Описание задачи

Описание должно быть необходимым и достаточным.

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

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

Не забудьте описать:

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

Описание должно учитывать платформенные особенности, не допустите ошибочных расхождений в одинаковой функциональности.

Лайфхаки и советы

1. Структурируйте и будьте аккуратны. Разделяйте задачу на логические блоки, чтобы удобно было читать и находить информацию. Для начального заполнения задачи пользуйтесь шаблоном (например, YouTrack, который мы используем в работе, автоматически добавляет формат базовой задачи с местом для верстки, логики и сразу с базовым чек-листом, всем советуем, очень удобно).
2. Не допустите пересечения параллельных задач между разработчиками. Так вы получите увеличение трудозатрат на разрешение конфликтов и дублирование.
3. Ставьте задачи на любые изменения. Без этого вы не сможете доказать разработчику, что он сделал что-то не так. Устные договоренности ничего не значат! Без задачи изменения не будут протестированы тестировщиком. Кроме того, часто поставленные задачи служат единственным источником информации о поведении приложения. Отсутствие задачи в начале — недостаток информации потом.
4. Связь задач между платформами. Обязательно свяжите задачи про одинаковые фичи между двумя платформами в системе постановки задач. Так проще поддерживать актуальность описаний задач при изменениях на обеих платформах, догоняющий разработчик сможет узнать, кто делал задачу на другой платформе, и прочитать обсуждение.
5. Визуализация для задачи. Иногда схема, диаграмма или картинка опишет разработчику что-то понятнее, чем сложный текст — или хотя бы поможет быстрее разобраться в задаче.

Чек-лист для разработчика

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

1. наиболее старую поддерживаемую версию платформы — она же обычно и самая проблемная;
2. работу на маленьком девайсе;
3. темную тему;

Кроме того, в зависимости от задачи чек-лист может дополняться следующими пунктами:

• крайние кейсы для проверки;
• пустые состояния;
• состояния ошибок;
• подгрузка данных (если она постраничная);
• обновление данных (PTR);
• большие/маленькие данные;
• заглушки для текстов/картинок;
• горизонтальная ориентация.

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

Ожидаемый эстимейт по задаче

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

Шаги описания задачи

Итак, зафиксируем пройденный материал:

• Получите все необходимые требования. Убедитесь, что сами понимаете, что требуется реализовать.
• Подберите правильное название задачи.
• В самом начале описания задачи поясните разработчику ценность изменения.
• Добавьте путь до изменяемого экрана, если это не очевидно.
• Добавьте ссылки на макеты, если фича визуальная. Если есть разные состояния в зависимости от условий, описываемых в задаче, то добавьте ссылки в контексте конкретного кейса.
• Добавьте дополнительные ссылки на артефакты, которые требуются для выполнения задачи.
• Если предполагается переиспользование для реализации, явно укажите это.
• Укажите, если в будущем будет переиспользоваться, масштабироваться или меняться результат задачи.
• Если необходимо сохранение данных для будущего использования, укажите.
• Опишите функционально задачу и убедитесь в отсутствии пробелов в логике.
• Опишите всю необходимую информацию по сетевым запросам (запрос, ответ, что парсим, опциональность; не описывать неиспользуемые поля и указать, что их не парсим).
• Укажите, если данные получаются при каком-то условии — например, касаются только авторизованных пользователей, специальных заказов или аккаунтов и т.д.
• Укажите прошлые локальные данные, если они используются.
• Пропишите логику загрузки данных: есть ли постраничная подгрузка, активити и т.д.
• Укажите логику для пустых данных.
• Опишите разные форматы отображения для разных региональных параметров, форматов дат и т.д.
• Пропишите логику для обработки специальных ошибок.
• Если требуются какие-то ключи, то добавьте их для каждого типа сборки – QA/RC/Release.
• Убедитесь, что разработчики имеют доступ ко всем необходимым артефактам или сервисам.
• Добавьте аналитику по данной функции (возможно в другой задаче – подумайте и не забудьте).
• Дополните базовый чек-лист.
• Свяжите с задачей для другой платформы и другими задачами, если есть такая зависимость.
• Перечитайте всю задачу от начала до конца!

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

Примеры хорошо описанных задач

Эти задачи описаны достаточно полно, не вызвали вопросов у разработчиков.

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

Пример 2. Обратите внимание: описание разделено на логические блоки экрана, в задаче указано состояние, которое надо учесть на будущее и есть переход на ранее реализованный экран.

Пример 3. Здесь не забыли указать, что требуется предусмотреть использование для двух экранов, что подгрузка постраничная и делается немного заранее. Указаны специфичные кейсы с 0-датой, ошибкой загрузки и ошибкой подгрузки. В ответе указано, какие поля за что отвечают, явно указано, что не парсим.

Пример 4. Явно указано, что не нужно реализовывать из макета — разработчик не будет делать ничего лишнего. Указано сохранение данных для будущего использования. В чек-листе добавлены проверки на первое открытие приложения и на повторные с разным поведением.

Добавлена связь с другой задачей — по добавлению API к этому экрану.

Пример 5. Указаны кейсы для разных объемов данных (не помещается на одну строку — где-то проблема решается с помощью многоточия, где-то — переносом строки). В чек-листы также добавлена проверка.
Понятная работа с полями api. Указано, в каких форматах отображать текущий год и будущие даты.

Как ставить задачу разработчикам сайта, чтобы вас правильно поняли

Как сформулировать хотелки, решить проблемы на берегу и приблизить результат к сайту мечты: чеклист на постановку задач на разработку от Notamedia.

Привет! Я Аня, специалист по продукту в digital-агентстве Notamedia. Наш отдел проектирует сайты и мобильные приложения — выявляет требования и бизнес-цели, изучает предметную область, специфику и цели пользователей, создает архитектуру и интерфейсы будущего решения.

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

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

1. Редизайн текущего сайта. В результате редизайна у сайта меняется визуальное решение, а структура страниц и информация на них остаётся прежней.
2. Переработка текущего сайта. В этом случае меняется всё — визуальное решение, структура страниц, информация на них. При переработке могут добавляться новые функции и интеграции.
3. Создание нового сайта с нуля. Структура, информация и визуальное решение также создаются с нуля.

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

При переработке и создании сайта нужно сформулировать гораздо больше требований.

1. Цель разработки сайта.
2. Кто будет пользоваться сайтом, кто ваша целевая аудитория.
3. Сценарии пользователей.
4. Функционал сайта.
5. Структура сайта.
6. Контент.

Мы очень рекомендуем потратить на это время и силы, потому что, чем конкретнее вы расскажете, что именно вам нужно на новом сайте и какого итогового результата вы ждёте, тем точнее и ниже будет оценка стоимости от агентства. Если в проекте сайта есть какие-то белые пятна, то агентство делает приблизительный расчёт стоимости и закладывает больше рисков, которые увеличивают итоговую цену сайта.

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

0. Сформулируйте бизнес-цели сайта

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

Например, если вы только открываете небольшой магазин одежды, то у сайта может стоять цель ознакомления пользователя с ассортиментом магазина через сайт. Если бизнес пойдёт в гору, то могут появиться новые цели, например, увеличение продаж магазина не только через офлайн-точку, но и через сайт. А со временем, возможно, появится цель увеличения лояльности клиентов.

Чем конкретнее вы сформулируете цели, тем легче потом будет проверить, выполняет ли их сайт. Рекомендуем добавить в цели определённости в плане времени и объёма их достижения.

Один из эффективных способов ставить цели — инструмент SMART.

2. Напишите сценарии по каждой задаче

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

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

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

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

1. Из поисковой системы пользователь переходит на страницу услуги.
2. Пользователь изучает информацию по услуге.
3. Понимает, что эта услуга ему не подходит.
4. Находит в меню пункт «Услуги», нажимает на него и переходит на страницу списка услуг.
5. Выбирает подходящую на его взгляд услугу, нажимает на неё и переходит на её страницу.
6. Изучает информацию по услуге и понимает, что она ему потенциально подходит.
7. Хочет получить консультацию по услуге и нажимает кнопку отправки заявки.
8. В открывшейся форме заявки заполняет поля и отправляет её.
9. Получает сообщение об успешной отправке заявки.

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

3. Перечислите основной функционал будущего сайта

Часто люди не понимают, что кроется за словосочетанием «функционал сайта». Для упрощения понимания можно сказать так: функционал — это всё, что требует от пользователя больше, чем просто переход по ссылке.

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

Пример дашборда идей с учётом функциональных требований

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

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

Пример функционала сайта

Можно отталкиваться не только от сценариев, но и от задач пользователя. Например: если у пользователя на сайте есть задача получения консультации, то вам может пригодиться функционал живого чата.

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

4. Перечислите интеграции будущего сайта

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

Например: в случае, если вы планируете использовать живой чат, то сайту нужна интеграция с этим сервисом.

Когда требуется интеграция? Когда на сайт приходят данные из какой-то сторонней системы.

Например: список товаров из 1С передается на сайт. Или когда сайт сам отправляет данные в стороннюю систему. Например: пользователь подписывается на рассылку и данные о нём передаются в CRM.

5. Создайте предварительную структуру сайта

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

Например: если у пользователя задача найти нужную услугу, то ему понадобятся как минимум 2 страницы — страница списка услуг компании и страница самой услуги. А если пользователь будет искать страницу не через список услуг, а через функцию поиска по сайту, то вам понадобится ещё и страница результатов поиска.

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

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

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

6. Подготовьте контент для нового сайта

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

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

Также на этом этапе вы сможете понять, какой информации или изображений у вас нет, и заказать их заранее.

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

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

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

7. Расскажите агентству о существующих ограничениях разработки

Подумайте над тем, что может внести ограничения в проект.

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

Ещё одно потенциальное ограничение — разработка сайта на какой-то определённой платформе. Например, вам важно, чтобы новый сайт был разработан на Битриксе, потому что у вас в компании уже есть другие продукты из этой инфраструктуры.

8. Выберите человека, который будет отвечать за проект нового сайта

После того, как вы подготовили все материалы по сайту, нужно решить, кто в вашей компании будет коммуницировать с агентством на протяжении всего времени работы над сайтом. Желательно, чтобы это был человек, совмещающий в себе компетенции по бизнесу и IT. Если новый сайт планируется объёмным, то готовьтесь к тому, что участие в проекте будет занимать значительное время вашего сотрудника.

9. Определите круг лиц, которые будут принимать решения по сайту

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

10. Ответьте на уточняющие вопросы

Итак, основная работа проделана. Дальше вам останется ответить на несколько уточняющих вопросов.

1. Какое доменное имя будет у вашего сайта?
2. Нужна ли будет адаптивная версия сайта для мобильных устройств?
3. Понадобятся ли другие языковые версии, кроме русского языка?
4. На какие регионы будет рассчитан сайт?
5. Какие сроки и предполагаемый бюджет проекта?

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

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

6 правил постановки задач, которые сделают ваших сотрудников эффективнее

Согласны, что в любом деле должны быть правила? Мы — да, и правила для постановки задач в Worksection тоже существуют!

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

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

Для тех, кому лень читать — видеоверсия на нашем Youtube Worksection

Правило № 1 — Не ставьте задачи устно

Бывало такое, что за обедом или в коридоре сотрудники просят друг у друга что-то сделать, иногда даже очень важные задачи, а в итоге забывают про них? Конечно бывало и это абсолютно нормально и естественно. Но в результате — задача забыта. Сотрудникам нужно это понимать и полностью искоренить факт принятия и постановки устных задач.

Например, Евгений Некоз установил правило в своей компании: «Все, что устно, того не существует». И разрешает своим сотрудникам не делать задачи, которые поставлены устно. Даже если это он сам их поставил. Все задачи должны быть записаны и мы считаем, что это правильный подход.

Правило № 2 — Понятно называйте задачи

Название задачи должно быть максимально разжевано и понятно. Так, как если бы вы объясняли, что сделать своей бабушке. В названии задачи должен быть максимально подробно указан глагол-действие «что сделать» и конечный результат.

Плохо: «Кофе в офис» Хорошо: «Позвонить в компанию Cofetrade (044-23456789) и заказать кофе „Jacobs“ на 3 месяца»

От того, насколько понятно и правильно названа задача зависит ее правильное и своевременное выполнение.

Обычно, все наши важные задачи сложны. И эти задачи требуют того, чтобы мы вначале подумали перед тем, как начать делать. Поскольку это довольно энергозатратно и люди подсознательно этого избегают. Поэтому если у вас есть список задач: «Важные-но-подумать» и «Простые-просто-делаю» — человек автоматически выберет простую. В результате важные будут прокрастинироваться (откладываться) максимально до дедлайна.

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

Для компаний с типовыми задачами будет полезно сразу договориться про единую терминологическую базу. Тогда все будет «по полочкам» и облегчит поиск или анализ задач. Главное, чтобы все в компании это понимали и тем самым экономили время друг друга.

Правило № 3 — Пишите максимально подробное описание к задаче. Так, чтобы не оставалось вопросов

Описание также экономит огромное количество времени. В нем должны быть все необходимые материалы для выполнения задачи. Это могут быть: нужные контакты, особенности задачи, файлы. И не забывайте про детали, без которых задачу невозможно сделать. Например, если нужно поехать на встречу — укажите точный адрес.

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

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

Правило № 4 — Обязательно указывайте сроки

Если у задачи нет времени завершения, то она скорее похожа на легкое пожелание. Все потому, что:

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

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

Когда появляются новые задачи, сложно планировать работу, если уже существующие задачи без сроков.

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

Правило № 5 — Вносите временные затраты

Знать сколько времени тратится на задачи важно как для руководителя, так и для сотрудников. К сожалению, никто не любит считать и вносить время. За этим сложно следить, пока вносить время не вошло в привычку.

Важно сразу всем сотрудникам разъяснить, что вносить временные затраты неприятная штука, но очень важная.

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

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

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

Правило № 6 — Записывайте конечный результат в задачу

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

Также вы, например, можете создать сет меток в Worksection «Результат работы»: «Сделано хорошо», «Сделано плохо» и «Сделано отлично» и устанавливать их при выполнении задания. Позже сможете посмотреть и выяснить причины, почему у вас все «Сделано п̶л̶о̶х̶о̶ отлично».

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

P. S. Есть еще одно негласное правило. Устанавливайте свою фотографию в профиле. Гораздо приятнее общаться с живым человеком и, глядя на фото, сразу ясно кто поставил задачу или написал комментарий:)

Как правильно ставить задачи программистам

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

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

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

Рассмотрим несколько абстрактных интернет-магазинов. В одном из них разрешено оформление заказа для неавторизованного посетителя, в другом — не разрешено, третий же в процессе оформления заказа производит автоматическое создание учетной записи пользователя, да еще и с «теневой» подпиской на рассылку рекламных предложений. В одном из магазинов информация о товарах и ценах автоматически обновляется в ходе периодического обмена данными с системой управления торговлей, в другом товары создаются и редактируются вручную, в третьем вообще импортируются из таблиц Excel с помощью специально созданного для этой цели скрипта. В магазине одежды или обуви покупатель должен выбрать размер и цвет приобретаемого товара (такие сочетания в ряде «движков» интернет-магазинов именуются торговыми предложениями), магазин бытовой техники, как правило, предлагает к своим товарам ряд расширенных программ гарантийного и постгарантийного обслуживания, магазин электроинструмента посоветует одновременно с перфоратором приобрести подходящие для него буры, зубила и пики. Один магазин предоставляет только почтовую доставку и самовывоз, тогда как другой способен определять местоположение покупателя и на основании этих данных рассчитать стоимость доставки курьерской службой. Где же среди всего перечисленного затерялся тот самый типовой, общий для всех набор функций, присущий всем этим магазинам, так сказать, «из коробки»?

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

Из всех приведенных рассуждений и вытекает взгляд исполнителя на постановку задачи. Задача, сформулированная очень лаконично («нужно сделать, чтобы вот там-то стало вот так-то») в абсолютном большинстве случаев вызовет огромное количество встречных вопросов. Также нередки случаи, когда задача поставлена, на первый взгляд, довольно развернуто, подробно описана проблематика, приведены примеры, но беда в одном: все перечисленное изложено исключительно с точки зрения человека, находящегося в контексте бизнес-процессов проекта, для которого проблема очевидна. Для программиста задача, поставленная исключительно с точки зрения бизнес-процессов, как правило, малопонятна.

Пример: поступила задача со следующей формулировкой «На примере набора иллюстрирую проблему. Данный набор состоит из: — XXX руб, — YYY руб, сумма по ценам отдельных комплектующих = XXX + YYY = ZZZ руб. А цена набора — XYZ руб. Как можно решить данную проблему? Т.е. мы предлагаем более привлекательные цены клиентам, если они берут наборы, а не товары по отдельности.» Проверка, проведенная исполнителем, показала, что сайт показывает цены верно: за товар 1 XXX руб, за товар 2 YYY руб, за набор — XYZ руб, что меньше суммарной цены двух товаров. Появляется вопрос — в чем состоит проблема? Вероятно, для заказчика она более чем очевидна и прямо вытекает из приведенных ценовых выкладок. Но для программиста очень полезной оказалась бы информация о том, что заказчик ожидает получить на выходе, после решения заявленной задачи. Другими словами, в тексте постановки задачи приведен пример с конкретными товарами, но никак не разъясняется ожидаемый конечный результат.

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

Грамотно поставленная задача способна минимизировать продолжительность подготовительного периода и максимально быстро приступить к оценке и непосредственному выполнению. Само собой, полностью избежать подготовительного периода невозможно и чем масштабнее запрошенная доработка, тем большего периода подготовки она требует. К особо крупным работам невозможно приступить, не имея под рукой утвержденного заказчиком ТЗ, в противном случае работа погрязнет в бесконечной вариативности. Тем не менее, качественная постановка даже крупной задачи позволит составить весь стартовый набор документов с гораздо меньшими трудозатратами, чем если первоначальная формулировка вызовет больше вопросов, чем понимания цели доработки.

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

Пример грамотной постановки задачи: «В настоящий момент на странице корзины работает следующая логика: в момент загрузки страницы проверяется общая сумма товаров и на основании этого устанавливается тот или иной обработчик нажатия кнопки “оформить заказ”; в случае изменения количества позиций (и как следствие — изменения общей суммы заказа) функционал нажатия кнопки «оформить заказ» никак не меняется; требуется поставить работу кнопки «Оформить заказ» в зависимость от текущей итоговой суммы заказа без перезагрузки страницы». Как нетрудно видеть, подробно изложена текущая ситуация и, что особенно важно, разъяснена ожидаемая цель задачи. Такая формулировка вызовет минимум недоумения и встречных вопросов даже у человека, впервые увидевшего данный проект.

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

Похожие публикации:

1. Как очистить базу данных mysql в phpmyadmin
2. Как сохранить файл conf
3. Почему затруднена мобильная связь в лесу
4. Что такое перегретая вода