Постановка задачи как написать


Загрузить PDF


Загрузить PDF

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

  1. Изображение с названием Feel Good About Yourself Step 13

    1

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

    • К примеру, вы работаете в небольшой авиакомпании, и вы заметили, что пассажиры, садясь в самолет, тратят время и прочие ресурсы неэффективно. В таком случае сначала нужно описать идеальную ситуацию, при которой все работает должным образом, например: «Правила посадки пассажиров компании АБВ-Авиалинии должны быть построены так, чтобы пассажиры могли попасть на борт самолета самым эффективным способом, благодаря чему самолет мог бы взлететь как можно скорее. Процесс посадки следует оптимизировать, чтобы он занимал меньше времени, однако он также должен быть понятным для пассажиров».
  2. Изображение с названием Have a Good Job Interview Step 3

    2

    Опишите проблему. Как говорил изобретатель Чарльз Кеттеринг, «правильно поставленная задача уже наполовину решена».[1]
    Одна из самых важных целей постановки задачи (если не самая важная) заключается в объяснении проблемы читателю ясно, четко и просто. Кратко изложите суть проблемы, которую вы хотите решить. Это сразу же отсечет все ненужное и выведет на первый план только самое важное. Если вы уже описали идеальную ситуацию, как предлагалось выше, можно начать следующий абзац со слов «однако» или «к сожалению», чтобы объяснить, что проблема, о которой пойдет речь, мешает приблизить ситуацию к идеалу.

    • Предположим, вы считаете, что вам удалось разработать более эффективную систему посадки пассажиров на борт, чем классическая. В таком случае можно продолжить так: «Однако существующая система посадки пассажиров в компании АБВ-Авиалинии нерационально расходует время и другие ресурсы предприятия. Занимая время работников, существующая система не позволяет компании стать более конкурентоспособной и замедляет процесс посадки, создавая невыгодный образ компании».
  3. Изображение с названием Apply for an Entrepreneurial Grant Step 10

    3

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

    • Возвращаясь к авиакомпании, можно описать влияние проблемы на финансовую сторону вопроса так: «Нерациональность существующей системы существенно влияет на прибыль компании. В среднем при каждой посадке впустую тратится около 4 минут времени, что составляет 20 человеко-часов ежедневно на всех рейсах компании. Это равняется 22500 рублей в сутки, более восьми миллионов рублей в год.
  4. Изображение с названием Get a Patent Step 9

    4

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

    • В некоторых работах необходимо приводить конкретные ссылки с описанием, в других достаточно упомянуть источник информации вкратце. Если вы не уверены, обратитесь к руководству или преподавателю.
    • Вернемся к предложениям, которые мы использовали выше. Мы описали стоимость проблемы, но не объяснили, откуда мы взяли эти цифры. Чтобы описать все подробнее, можно начать так: «…На основании внутренней информации о трудозатратах [1] можно сделать вывод, что в среднем при текущей системе в сутки впустую тратится 20 человеко-часов. Сотрудникам, контролирующим посадку, платят примерно 1000 рублей в час, что в сумме дает 22500 рублей в сутки и более восьми миллионов рублей в год». Обратите внимание на ссылку. Если бы это был настоящий документ, ссылка вела бы на пункт в приложении, в котором была бы точная выкладка по времени и суммам.
  5. Изображение с названием Deal With Different Problems in Life Step 17

    5

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

    • Если говорить об авиакомпании, решением проблемы будет внедрение новой системы, разработанной вами, поэтому нужно кратко объяснить, в чем ее суть, не вдаваясь в подробности. Можно сказать так: «С помощью улучшенной системы посадки, предложенной Иваном Петровым, компания сможет размещать пассажиров на борту одновременно с двух концов самолета, что позволит исключить потерю времени». Далее можно описать основные принципы системы, но лишь в одном-двух предложениях, поскольку основная часть анализа будет приводиться ниже.
  6. Изображение с названием Solve a Problem Step 4

    6

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

    • Можно кратко описать, какую выгоду компания может извлечь из сэкономленных денег. Попробуйте сформулировать мысль таким образом: «АБВ-Авиалинии выиграют от новой системы. К примеру, сэкономленные 8 миллионов рублей в год можно направить на развитие компании — допустим, на открытие новых рейсов на популярных направлениях. Кроме того, если АБС-Авиалинии станут первой компанией в России, где будет использоваться такая система, это сделает предприятие законодателем тенденций в отрасли, направленных на повышение удобства и уменьшения стоимости перелетов».
  7. Изображение с названием Start a Letter Step 7

    7

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

    • В примере с авиалиниями можно написать так: «Оптимизация существующей системы и внедрение новых принципов позволит компании оставаться конкурентоспособной. В этой работе анализируются новые подходы к процессу посадки пассажиров, оценивается их осуществимость и рассматриваются конкретные шаги по внедрению системы». Такая фраза суммирует все сказанное: и то, что текущая система является нерациональной, и то, что новая система будет лучше. В ней также есть пояснение, чего читателю ожидать от последующего текста.
  8. Изображение с названием Write Your Congressional Representative Step 6

    8

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

    • Например, вам нужно исследовать проблему компаний, которые за деньги пишут курсовые и дипломные работы, чтобы студенты выдавали их за свои. В качестве формулировки проблемы можно использовать такую фразу: «Покупка курсовых и дипломных работ подрывает учебный процесс и дает преимущество обеспеченным студентам, но с ней можно бороться с помощью более эффективных программ для анализа цифровой информации, которые следует предоставлять преподавателям».
    • Иногда формулировка должна находиться в определенном месте в работе. Посоветуйтесь с преподавателем, если не уверены, где ее следует разместить.
  9. Изображение с названием Apply for an Entrepreneurial Grant Step 8

    9

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

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

    Реклама

  1. Изображение с названием Write a Speech Introducing Yourself Step 5

    1

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

    • В такой работе не должно быть личных комментариев, поскольку это удлиняет текст и не добавляет ему веса. У вас будет возможность добавить больше слов в основной части работы, если тема позволяет это.
  2. Изображение с названием Write a Speech Introducing Yourself Step 9

    2

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

    • Для кого я пишу?
    • Почему я обращаюсь к этой аудитории?
    • Владеет ли аудитория терминами и понятиями так же хорошо, как я?
    • Так же аудитория относится к проблеме, как я, или иначе?
    • Почему аудиторию должна интересовать эта проблема?
  3. Изображение с названием Write a Book Report Step 6

    3

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

    • Например, если вы пишете для врачей с соответствующим образованием, вы можете быть уверены, что они знают значение слова «метакарпальный». Но если вы пишете для аудитории, состоящей и из врачей, и из инвесторов медицинского центра, у которых может не быть медицинского образования, следует пояснить это слово.
  4. Изображение с названием Write a Speech Introducing Yourself Step 7

    4

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

    • Следует касаться лишь тех проблем, для которых вы можете предложить решение, не вызывающее у вас сомнений. Если вы не уверены в каком-то решении, следует сузить тему и скорректировать постановку задачи.
    • Чтобы не уходить в сторону, стоит дописать основную часть документа, а потом перейти к написанию постановки задачи. Так вы сможете отталкиваться от основной части и не строить догадок о том, что вы можете написать далее.
  5. Изображение с названием Accept an LGBT Family Member Step 3

    5

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

    • Например, вы хотите предложить проект нового здания. Вам нужно будет объяснить, кто выиграет от появления нового здания, что потребуется для строительства, где будет идти строительство, когда оно начнется и почему это здание нужно городу.
  6. Изображение с названием Cite the Quran Step 8

    6

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

    • Практически единственный способ немного «разбавить» текст в работе на гуманитарную тему — привести цитату или добавить эпиграф. Но даже в этих случаях цитата должна соотноситься с темой и проблемой работы, а все остальное должно быть написано в деловом стиле.
  7. Изображение с названием Do Research Step 17

    7

    Всегда перечитывайте текст, чтобы найти ошибки. Это обязательное требование ко всем серьезным трудам. Любой текст нужно обязательно вычитать. Завершив работу над текстом, заново перечитайте его. Гладко ли он написан? Удалось ли вам внятно изложить мысли? Логически ли располагаются фрагменты текста? Если нет, вносите изменения сейчас. Когда будете довольны работой, заново проверьте текст на наличие ошибок, опечаток и неправильного форматирования.

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

    Реклама

Источники

Об этой статье

Эту страницу просматривали 33 231 раз.

Была ли эта статья полезной?

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

Время на прочтение
7 мин

Количество просмотров 14K

«Эти разработчики опять ничего не поняли!» — возмущается заказчик мобильного приложения. Но мы все знаем, что у разработчиков тонкая душевная организация и куча злых мемов на случай недопонимания с заказчиком. Чтобы не попасть в череду уточнений, согласований и — самое плохое — исправлений ошибок, нужно просто грамотно написать задачу для специалистов. Как это сделать, рассказывает руководитель проектного офиса “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. Описание задачи хорошо тем, что указана ценность реализации для пользователя, есть необходимые ссылки на макеты, указаны состояние при открытии, стейт во время загрузки, стейты успеха и ошибок.

Пример 1.

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

Пример 2.

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

Пример 3.

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

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

Пример 4.

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

Пример 5.

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

07 июня 2021 Время прочтения статьи: 7 минут


54417

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

Что такое постановка задач и почему она важна

Часто компании закрываются в первый год не только из-за высокой конкуренции, но и из-за неправильного выстраивания процессов внутри. Любая работа состоит из постановки целей и задач. Если цель — это результат, то задача — ответ на вопрос «как это сделать?». Например, ваша цель — продвигать бизнес в социальных сетях. Тогда задачи, в зависимости от специфики — собрать команду из SMM-менеджера, дизайнера и копирайтера, разработать и согласовать стратегию продвижения, рассчитать бюджет и проанализировать результаты. Часто задачи связаны между собой: результат одной зависит от другой. 

Без планирования и управления нельзя: хаотичные и несогласованные действия сотрудников наносят ущерб компании. И наоборот — хорошо организованный труд в команде способствует плодотворной работе. 

Так, рост конверсии в покупки связан с эффективностью сотрудников, принимающих звонки: продавцов, менеджеров и операторов call-центра. Если клиент долго ждет или не может получить ответ на вопрос, он уйдет к конкурентам. Система Workforce Management MANGO OFFICE решает вопросы с организацией работы первой линии. Сервис поможет определить, сколько нужно сотрудников для выполнения задачи, составить оптимальный график и проанализировать работу сотрудников в режиме реального времени.

Виды задач

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

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

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

  • Долгосрочные. Касаются развития бизнеса в перспективе и ставятся на определенный срок. Например, увеличить выручку на 15% за год или открыть офис в каждом районе Москвы в течение пяти лет. Такие задачи не обсуждают на ежедневных планерках, это часть стратегического планирования, которым занимается руководство. 

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

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

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

Распределение ролей

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

При формировании команды нужно учитывать не только hard skills, но и личные качества сотрудника. Это влияет на эффективность и отношения в коллективе. Каждый должен выполнять задачи, соответствующие своему психотипу. Дисциплинированному сотруднику, привыкшему к контролю, легче выполнять рутинную работу, а человеку с творческим мышлением — креативить. Руководителю нужно распознавать личностные качества и поручать задачи сотрудникам с релевантными навыками и опытом. 

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

Конкретизация действия и результата

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

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

Назначение ответственных

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

Ограничение по срокам

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

Трекинг задач

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

  • для небольших компаний: Google Docs, Trello, Basecamp, Wunderlist, Slack;

  • для крупных проектов: JIRA, Redmine, Яндекс.Трекер;

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

SMART-цели в постановке задач

SMART — это способ описания задач. Он был разработан Джорджем Т. Дораном в 80-х годах прошлого века, но до сих пор  не утратил актуальности. Метод устанавливает критерии правильной постановки задач. 

  • Конкретность (specific). Цель должна быть определенной и понятной: не «обзвонить клиентов», а «получить обратную связь по вчерашним встречам». 

  • Измеримость (measurable). Добавьте в формулировку количественный показатель. Это поможет оценить результат и даст ориентир сотрудникам. Пример: увеличить выручку до 10 млн, провести 15 рабочих встреч. 

  • Достижимость (achievable). Для мотивации важно, чтобы у сотрудника были ресурсы для выполнения работы, а ее результат был реальным, осязаемым. Если требовать невозможного, команда выгорает и перестает стараться.

  • Релевантность (relevant). Проверьте значимость и согласованность задач, их соответствие глобальным целям компании. Противоречивые и неактуальные требования разрушают работу и вызывают недовольство у сотрудников. 

  • Ограниченность в сроках (time bound). Работа движется быстрее, если установлены временные рамки: можно распределять нагрузку, расставлять приоритеты.  

6.png

Ошибки руководителя при постановке задач

Чтобы устранить ошибки, их нужно увидеть. Разберем несколько основных.

Тон речи

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

Неправильная постановка дедлайнов

Для кого-то «скоро» — это через два дня, а для кого-то через 30 минут. Не стоит надеяться, что у всех одинаковые представления о времени. Такие недопонимания могут сказаться на работе. Лучше установите даты контрольных точек и окончательного дедлайна. 

Отсутствие примеров

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

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

С сервисом Контакт-центр MANGO OFFICE вы сможете создать эффективный скрипт продаж и ускорить процесс обучения новых сотрудников. Система аналитики поможет отследить эффективность операторов и улучшить каждый этап работы с клиентом. 

Отсутствие обратной связи

Бывает, что сотрудник плохо выполняет работу даже после подробных разъяснений. Возможно, он не понял задачу и чего от него ждут. Чтобы исключить ошибки, добивайтесь обратной связи. Спросите, как именно команда будет выполнять работу, нужна ли дополнительная информация. Это кажется лишним, но именно недопонимание становится частой причиной конфликтов. Избегайте закрытых вопросов, вроде «Вам все понятно?» — они не мотивируют к диалогу. 

Примеры правильной постановки задач

Посмотрим, как правильно ставить задачи, пользуясь правилами. 

Цель: увеличить продажи. Задачи:

  • нанять двух сотрудников до 31.04;

  • увеличить количество сделок менеджеров на 15%, используя технологию личных продаж;

  • поднять продажи по холодным звонкам с 15 до 25%, применяя новый скрипт. 

Цель: увеличить прибыль с единичной продажи. Задачи:

  • увеличить средний чек на 25% с помощью апселлинга;

  • повысить цены на 5% и поменять ценники во всех магазинах до 21 сентября. 

Использование CRM в постановке задач

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

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

Заключение

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


Download Article


Download Article

A problem statement is a short, succinct explanation of a problem a business is facing and a proposed solution to the problem. Problem statements can be effective ways to define an issue and communicate a solution within a short span of time. Before you write your problem statement, think about the problem and your proposed solution, and be prepared to back it up with facts!

Sample Problem Statements

  1. Image titled Write a Problem Statement Step 1

    1

    Describe the «ideal» state of affairs. There are lots of different ways to write a problem statement — some sources will recommend jumping right to the problem itself, while others recommend providing background context first so that problem (and its solution) are easier to understand for the reader. If you’re ever unsure of how to begin, opt for the latter option. While conciseness is something every piece of practical writing should aim for, it’s even more important to be well-understood. Start by describing how things should work. Before you even mention your problem, explain in a few sentences how things would be if the problem didn’t exist.

    • For instance, let’s say that you work at a major airline and that you’ve noticed that the way passengers board your planes is an inefficient use of time and resources. In this case, you might begin your problem statement by describing an ideal situation where the boarding system isn’t inefficient that the company should shoot for, like this: «The boarding protocols used by ABC Airlines should aim to get each flight’s passengers aboard the plane quickly and efficiently so that the plane can take off as soon as possible . The process of boarding should be optimized for time-efficiency but also should be straightforward enough that it can be easily understood by all passengers.»
  2. Image titled Write a Problem Statement Step 2

    2

    Explain your problem. In the words of the inventor Charles Kettering, «A problem well-stated is a problem half-solved.» One of the most important goals (if not the most important goal) of any problem statement is to articulate the problem being addressed to the reader in a way that’s clear, straightforward, and easy to understand.[1]
    Succinctly summarize the problem you intend to solve — this cuts to the heart of the issue immediately and positions the most important information in the problem statement near the top, where it’s most visible. If you’ve just started an «ideal» state of affairs as suggested above, you may want to start your sentence with phrasing like «However, …» or «Unfortunately, …» to show that the problem you’ve identified is what is preventing the ideal vision from being a reality.

    • Let’s say that you think you’ve developed a quicker, more efficient system for getting passengers aboard our planes than the typical «back to front» seating system. In this case, you might continue with a few sentences like, «However, ABC Airline’s current passenger boarding system is an inefficient use of the company’s time and resources. By wasting employee man-hours, the current boarding protocols make the company less competitive, and by contributing to a slow boarding process, they create an unfavorable brand image.»
    • Try to stress the problem’s urgency in your explanation.[2]

    Advertisement

  3. Image titled Write a Problem Statement Step 3

    3

    Explain your problem’s financial costs. Soon after you state your problem, you’ll want to explain why it’s a big deal — after all, no one has the time or resources to try to solve every single minor problem. In the business world, money is almost always the bottom line, so you’ll want to try to highlight the financial impact of your problem on the company or organization you’re writing for. For instance, is the problem you’re discussing keeping your business from making more money? Is it actively costing your business money? Is it damaging your brand image and thus indirectly costing your business money? Be as exact and specific about the financial burden of your problem — try to specify an exact dollar amount (or a well-supported estimate) for your problem’s cost.

    • For our airline example, you might proceed to explain the problem’s financial cost like this: «The inefficiency of the current boarding system represents a significant financial burden for the company. On average, the current boarding system wastes roughly four minutes per boarding session, resulting in a total of 20 wasted man-hours per day across all ABC flights. This represents a waste of roughly $400 per day or $146,000 per year.»
  4. Image titled Write a Problem Statement Step 4

    4

    Back up your assertions. No matter how much money you claim your problem is costing your company, if you can’t back up your claims with reasonable evidence, you may not be taken seriously. As soon as you start making specific claims about how serious your problem is, you’ll need to start supporting your statements with evidence. In some cases, this may be from your own research, from data from a related study or project, or even from reputable third-party sources.

    • In some corporate and academic situations, you may need to explicitly reference your evidence in the text of your problem statement, while in other situations, it may be enough to simply use a footnote or another form of shorthand for your citations. If you’re unsure, ask your boss or teacher for advice.
    • Let’s reexamine the sentences used in the previous step. They describe the cost of the problem but don’t explain how this cost was found. A more thorough explanation might include this: «…Based on internal performance tracking data,[1] on average, the current boarding system wastes roughly four minutes per boarding session, resulting in a total of 20 wasted man-hours per day across all ABC flights. Terminal personal are paid an average of $20 per hour, so this represents a waste of roughly $400 per day or $146,000 per year.» Note the footnote — in an actual problem statement, this would correspond to a reference or appendix containing the data mentioned.
  5. Image titled Write a Problem Statement Step 5

    5

    Propose a solution. When you’ve explained what the problem is and why it’s so important, proceed to explain how you propose to deal with it.[3]
    As with the initial statement of your problem, your explanation of your solution should be written to be as clear and concise as possible. Stick to big, important, concrete concepts and leave any minor details for later — you’ll have plenty of opportunities to get into every minor aspect of your proposed solution in the body of your proposal.

    • In our airline example, our solution to the problem of inefficient boarding practices is this new system you’ve discovered, so you should briefly explain the broad strokes of this new system without getting into the minor details. You might say something like, «Using a modified boarding system proposed by Dr. Edward Right of the Kowlard Business Efficiency Institute which has passengers board the plane from the sides in rather than from the back to the front, ABC Airlines can eliminate these four minutes of waste.» You might then go on to explain the basic gist of the new system, but you wouldn’t use more than a sentence or two to do this, as the «meat» of our analysis will be in the body of the proposal.
  6. Image titled Write a Problem Statement Step 6

    6

    Explain the benefits of the solution. Again, now that you’ve told your readers what should be done about the problem, it’s a very good idea to explain why this solution is a good idea.[4]
    Since businesses are always trying to increase their efficiency and earn more money, you’ll want to focus primarily on the financial impact of your solution — which expenses it will reduce, which new forms of revenue it will generate, and so on. You can also explain non-tangible benefits, like improved customer satisfaction, but your total explanation shouldn’t be too much longer than a few sentences to a paragraph.

    • In our example, you might briefly describe how our company could conceivably benefit from the money saved with our solution. A few sentences along these lines might work: «ABC Airlines stands to benefit substantially from the adoption of this new boarding program. For instance, the $146,000 in estimated yearly savings can be re-directed to new sources of revenue, such as expanding its selection of flights to high-demand markets. In addition, by being the first American airline to adopt this solution, ABC stands to gain considerable recognition as an industry trendsetter in the areas of value and convenience.»
  7. Image titled Write a Problem Statement Step 7

    7

    Conclude by summarizing the problem and solution. After you’ve presented the ideal vision for your company, identified the problem keeping you from achieving this ideal, and suggested a solution, you’re almost done. All that’s left to do is to conclude with a summary of your main arguments that allows you to transition easily into the main body of your proposal. There’s no need to make this conclusion any longer than it needs to be — try to state, in just a few sentences, the basic gist of what you’ve described in your problem statement and the approach you intend to take in the body of the article.

    • In our airline example, you might conclude like this: «Optimization of current boarding protocols or adoption of new, more-effective protocols is crucial for the continued competitiveness of the company. In this proposal, the alternative boarding protocols developed by Dr. Right are analyzed for their feasibility and steps for effective implementation are suggested.» This sums up the main point of the problem statement — that the current boarding procedure isn’t very good and that this new one is better — and tells the audience what to expect if they continue reading.
    • Be sure to mention the possible consequences if the solution isn’t implemented.[5]
  8. Image titled Write a Problem Statement Step 8

    8

    For academic work, don’t forget a thesis statement. When you have to write a problem statement for school, rather than for work, the process will be largely the same, but there may be extra items you’ll need to take into account to assure a good grade. For instance, many composition classes will require you to include a thesis statement in your problem statement. The thesis statement (sometimes just called the «thesis») is a single sentence that summarizes your entire argument, boiling it down to its bare essentials. A good thesis statement identifies both the problem and the solution as succinctly and clearly as possible.

    • For instance, let’s say you’re writing a paper on the problem of academic essay mills — companies that sell pre-written and/or custom works for students to purchase and turn in as their own work. As our thesis statement, you might use this sentence, which acknowledges the problem and the solution we’re about to propose: «The practice of buying academic essays, which undermines the learning process and gives an advantage to rich students, can be combated by providing professors with stronger digital analysis tools.»
    • Some classes explicitly require you to put your thesis sentence at a certain place in your problem statement (for instance, as the very first or very last sentence). Other times, you’ll have more freedom — check with your teacher if you’re not sure.
  9. Image titled Write a Problem Statement Step 9

    9

    Follow the same process for conceptual problems. Not all problem statements are going to be for documents dealing with practical, tangible problems. Some, especially in academics (and especially in the humanities), are going to deal with conceptual problems — problems that have to do with the way you think about abstract ideas. In these cases, you can still use the same basic problem statement framework to present the problem at hand (while obviously shifting away from a business focus). In other words, you’ll want to identify the problem (often, for conceptual problems, this will be that some idea is not well-understood), explain why the problem matters, explain how you plan to solve it, and sum up all of this in a conclusion.

    • For instance, let’s say that we’re asked to write a problem statement for a report on the importance of religious symbolism in The Brothers Karamazov by Fyodor Dostoevsky. In this case, our problem statement should identify some poorly-understood aspect of the religious symbolism in the novel, explain why this matters (for instance, you might say that by better understanding the religious symbolism in the novel, it’s possible to draw new insights from the book), and layout how you plan to support our argument.
  10. Advertisement

  1. Image titled Write a Problem Statement Step 10

    1

    Be concise. If there’s one thing to keep in mind when writing problem statements, it’s this. Problem statements shouldn’t be any longer than they need to be to accomplish their task of laying out the problem and its solution for the reader. No sentence should be wasted. Any sentence that doesn’t directly contribute to the problem statement’s goals should be removed. Use clear, direct language. Don’t get bogged down in minor details — problem statements should deal only with the essentials of your problem and solution. In general, keep your problem statement as short as possible without sacrificing its informativeness.

    • A problem statement is no place to add your own personal commentary or «flavor», as this makes the problem statement longer for no practical purpose. You may or may not have the opportunity to be more long-winded in the body of your document, depending on the seriousness of your topic and audience.
  2. Image titled Write a Problem Statement Step 11

    2

    Write to your audience. When making a problem statement, it’s important to remember that you’re writing for someone else, not for yourself. Different audiences will have different sets of knowledge, different reasons for reading, and different attitudes toward your problem, so try to keep your intended audience in mind as you write. You want your problem statement to be as clear and easy for your audience to understand as possible, which means you may need to change your tone, style, and diction from one audience to another. As you write, try to ask yourself questions like:

    • «Who, specifically, am I writing for?»
    • «Why am I addressing this audience?»
    • «Does this audience know all of the same terms and concepts as I do?»
    • «Does this audience share the same attitude as I do towards this problem?»
    • «Why should my audience care about this problem?»
  3. Image titled Write a Problem Statement Step 12

    3

    Don’t use jargon without defining it. As noted above, your problem statement should be written so that it’s as easy for your audience to understand as possible. This means that, unless you’re writing for a technical audience that is likely to be knowledgeable in the terminology of the field you’re writing about, you’ll want to avoid using technical jargon too heavily and to make sure that you define any pieces of jargon that you do use. Never make the assumption that your audience automatically has all of the technical knowledge that you do or you risk alienating them and losing readers as soon as they encounter terms and information they’re not familiar with.

    • For instance, if we’re writing for a board of highly-educated physicians, it may be OK to assume that they’ll know what the term «metacarpal» means. However, if we’re writing to an audience made up of both physicians and wealthy hospital investors who may or may not be medically trained, it’s a good idea to introduce the word «metacarpal» with its definition- the bone between the first two joints of the finger.
  4. Image titled Write a Problem Statement Step 13

    4

    Stick to a narrow, defined problem. The best problem statements aren’t sprawling, rambling pieces of writing. Instead, they’re focused on a single, easily-identified problem and its solution. Generally, narrow, defined topics are easier to write convincingly about than large, vague ones, so whenever possible, you’ll want to keep the scope of your problem statement (and thus the body of your document) well-focused. If this makes your problem statement (or the body of your document) short, this is usually a good thing (except in academic situations where you have minimum page limits for your assignment).

    • A good rule of thumb is to only address problems that you can definitively solve beyond a shadow of a doubt. If you’re not sure of a definitive solution that can solve your entire problem, you may want to narrow the scope of your project and change your problem statement to reflect this new focus.
    • To keep the scope of a problem statement under control, it can be helpful to wait until after completing the body of the document or proposal to write the problem statement. In this case, when you write your problem statement, you can use our actual document as a guideline so that you don’t have to guess about the ground you may cover when you write it.
  5. Image titled Write a Problem Statement Step 14

    5

    Remember the «five Ws». Problem statements should be as informative as possible in as few words as possible, but shouldn’t delve into minute details. If you’re ever in doubt of what to include in your problem statement, a smart idea is to try to answer the five Ws (who, what, where, when, and why), plus how. Addressing the five Ws gives your reader a good baseline level of knowledge to understand the problem and solution without treading into unnecessary levels of detail.

    • For instance, if you’re writing a problem statement to propose a new building development to your local city council, you might address the five Ws by explaining who the development would benefit, what the development would require, where the development should be, when construction should begin, and why the development is ultimately a smart idea for the city.
  6. Image titled Write a Problem Statement Step 15

    6

    Use a formal voice. Problem statements are almost always used for serious proposals and projects. Because of this, you’ll want to use a formal, dignified writing style (the same as the style hopefully used for the body of the document) in the problem statement. Keep your writing clear, plain, and direct. Don’t attempt to win your reader over by taking a friendly or casual tone in your problem statement. Don’t use humor or jokes. Don’t include pointless asides or anecdotes. Don’t use slang or colloquialisms. Good problem statements know that they have a job to accomplish and don’t waste any time or ink on unnecessary content.

    • The closest you can usually get to including purely «entertaining» content in academic writing in the humanities. Here, occasionally, it’s possible to encounter problem statements that begin with a quote or epigraph. Even in these cases, however, the quote has some bearing on the problem being discussed and the rest of the problem statement is written in a formal voice.
  7. Image titled Write a Problem Statement Step 16

    7

    Always proofread for errors. This is a must for all forms of serious writing — no first draft has ever existed that couldn’t have benefited from the careful eye of a good proofreader. When you finish your problem statement, give it a quick read. Does it seem to «flow» properly? Does it present its ideas coherently? Does it seem to be logically organized? If not, make these changes now. When you’re finally satisfied with the structure of your problem statement, double-check it for spelling, grammar, and formatting errors.

    • You’ll never regret re-reading your problem statement before you turn it in. Since, by its very nature, the problem statement is usually the first part of a proposal or report that someone will read, any errors here will be especially embarrassing for you and can even reflect negatively on your entire document.
  8. Advertisement

Add New Question

  • Question

    What is a problem statement?

    Joe Simmons

    Joe Simmons is a Corporate Trainer based in West Palm Beach, Florida. Joe specializes in operations management, leadership, learning and development, and employee training to help employees become high-performing teams. He holds a Bachelor’s degree in Marketing from The University of South Florida. Joe’s coaching has helped numerous organizations with employee retention, revenue growth, and team productivity.

    Joe Simmons

    Corporate Trainer

    Expert Answer

    A problem statement is a short, succinct explanation of a problem that a business is facing, along with a proposed solution to the said problem. Basically, problem statements help you describe an issue and offer a solution in a short format.

  • Question

    What are the 5 elements of a problem statement?

    Joe Simmons

    Joe Simmons is a Corporate Trainer based in West Palm Beach, Florida. Joe specializes in operations management, leadership, learning and development, and employee training to help employees become high-performing teams. He holds a Bachelor’s degree in Marketing from The University of South Florida. Joe’s coaching has helped numerous organizations with employee retention, revenue growth, and team productivity.

    Joe Simmons

    Corporate Trainer

    Expert Answer

    The first element would be the problem, and the second would be the solution. Then, you’d discuss the benefits of the solution, along with any potential consequences. As a final touch, explain both the urgency of the problem and the long-term consequences of not solving the problem quickly.

  • Question

    How do I write a problem statement?

    Community Answer

    Describe the problem, back it up with evidence and explain your solution.

See more answers

Ask a Question

200 characters left

Include your email address to get a message when this question is answered.

Submit

Advertisement

References

  1. Joe Simmons. Corporate Trainer. Expert Interview. 29 June 2021.
  2. Joe Simmons. Corporate Trainer. Expert Interview. 29 June 2021.
  3. Joe Simmons. Corporate Trainer. Expert Interview. 29 June 2021.
  4. Joe Simmons. Corporate Trainer. Expert Interview. 29 June 2021.
  5. Joe Simmons. Corporate Trainer. Expert Interview. 29 June 2021.
  6. http://www.personal.psu.edu/faculty/c/a/caw43/behrendwriting/problemstatements.html
  7. http://journals.lww.com/academicmedicine/fulltext/2001/09000/problem_statement,_conceptual_framework,_and.21.aspx

About This Article

Article SummaryX

The first thing you should do in a problem statement is to describe the ideal solution using words like «should.» Then, introduce the problem by using words like «Unfortunately» or «However,» followed by a clear 1-2 sentence description of what’s wrong. In order to emphasize why this problem is important, explain the financial cost the business will suffer if the problem goes unsolved, and back your statement up with data. For more advice on how to propose a solution, including how to explain your solution in concrete concepts, read on!

Did this summary help you?

Thanks to all authors for creating a page that has been read 3,576,409 times.

Reader Success Stories

  • Vitty Gee

    «I was working on my research proposal draft, and was challenged most with writing up a good research problem…» more

Did this article help you?


Download Article


Download Article

A problem statement is a short, succinct explanation of a problem a business is facing and a proposed solution to the problem. Problem statements can be effective ways to define an issue and communicate a solution within a short span of time. Before you write your problem statement, think about the problem and your proposed solution, and be prepared to back it up with facts!

Sample Problem Statements

  1. Image titled Write a Problem Statement Step 1

    1

    Describe the «ideal» state of affairs. There are lots of different ways to write a problem statement — some sources will recommend jumping right to the problem itself, while others recommend providing background context first so that problem (and its solution) are easier to understand for the reader. If you’re ever unsure of how to begin, opt for the latter option. While conciseness is something every piece of practical writing should aim for, it’s even more important to be well-understood. Start by describing how things should work. Before you even mention your problem, explain in a few sentences how things would be if the problem didn’t exist.

    • For instance, let’s say that you work at a major airline and that you’ve noticed that the way passengers board your planes is an inefficient use of time and resources. In this case, you might begin your problem statement by describing an ideal situation where the boarding system isn’t inefficient that the company should shoot for, like this: «The boarding protocols used by ABC Airlines should aim to get each flight’s passengers aboard the plane quickly and efficiently so that the plane can take off as soon as possible . The process of boarding should be optimized for time-efficiency but also should be straightforward enough that it can be easily understood by all passengers.»
  2. Image titled Write a Problem Statement Step 2

    2

    Explain your problem. In the words of the inventor Charles Kettering, «A problem well-stated is a problem half-solved.» One of the most important goals (if not the most important goal) of any problem statement is to articulate the problem being addressed to the reader in a way that’s clear, straightforward, and easy to understand.[1]
    Succinctly summarize the problem you intend to solve — this cuts to the heart of the issue immediately and positions the most important information in the problem statement near the top, where it’s most visible. If you’ve just started an «ideal» state of affairs as suggested above, you may want to start your sentence with phrasing like «However, …» or «Unfortunately, …» to show that the problem you’ve identified is what is preventing the ideal vision from being a reality.

    • Let’s say that you think you’ve developed a quicker, more efficient system for getting passengers aboard our planes than the typical «back to front» seating system. In this case, you might continue with a few sentences like, «However, ABC Airline’s current passenger boarding system is an inefficient use of the company’s time and resources. By wasting employee man-hours, the current boarding protocols make the company less competitive, and by contributing to a slow boarding process, they create an unfavorable brand image.»
    • Try to stress the problem’s urgency in your explanation.[2]

    Advertisement

  3. Image titled Write a Problem Statement Step 3

    3

    Explain your problem’s financial costs. Soon after you state your problem, you’ll want to explain why it’s a big deal — after all, no one has the time or resources to try to solve every single minor problem. In the business world, money is almost always the bottom line, so you’ll want to try to highlight the financial impact of your problem on the company or organization you’re writing for. For instance, is the problem you’re discussing keeping your business from making more money? Is it actively costing your business money? Is it damaging your brand image and thus indirectly costing your business money? Be as exact and specific about the financial burden of your problem — try to specify an exact dollar amount (or a well-supported estimate) for your problem’s cost.

    • For our airline example, you might proceed to explain the problem’s financial cost like this: «The inefficiency of the current boarding system represents a significant financial burden for the company. On average, the current boarding system wastes roughly four minutes per boarding session, resulting in a total of 20 wasted man-hours per day across all ABC flights. This represents a waste of roughly $400 per day or $146,000 per year.»
  4. Image titled Write a Problem Statement Step 4

    4

    Back up your assertions. No matter how much money you claim your problem is costing your company, if you can’t back up your claims with reasonable evidence, you may not be taken seriously. As soon as you start making specific claims about how serious your problem is, you’ll need to start supporting your statements with evidence. In some cases, this may be from your own research, from data from a related study or project, or even from reputable third-party sources.

    • In some corporate and academic situations, you may need to explicitly reference your evidence in the text of your problem statement, while in other situations, it may be enough to simply use a footnote or another form of shorthand for your citations. If you’re unsure, ask your boss or teacher for advice.
    • Let’s reexamine the sentences used in the previous step. They describe the cost of the problem but don’t explain how this cost was found. A more thorough explanation might include this: «…Based on internal performance tracking data,[1] on average, the current boarding system wastes roughly four minutes per boarding session, resulting in a total of 20 wasted man-hours per day across all ABC flights. Terminal personal are paid an average of $20 per hour, so this represents a waste of roughly $400 per day or $146,000 per year.» Note the footnote — in an actual problem statement, this would correspond to a reference or appendix containing the data mentioned.
  5. Image titled Write a Problem Statement Step 5

    5

    Propose a solution. When you’ve explained what the problem is and why it’s so important, proceed to explain how you propose to deal with it.[3]
    As with the initial statement of your problem, your explanation of your solution should be written to be as clear and concise as possible. Stick to big, important, concrete concepts and leave any minor details for later — you’ll have plenty of opportunities to get into every minor aspect of your proposed solution in the body of your proposal.

    • In our airline example, our solution to the problem of inefficient boarding practices is this new system you’ve discovered, so you should briefly explain the broad strokes of this new system without getting into the minor details. You might say something like, «Using a modified boarding system proposed by Dr. Edward Right of the Kowlard Business Efficiency Institute which has passengers board the plane from the sides in rather than from the back to the front, ABC Airlines can eliminate these four minutes of waste.» You might then go on to explain the basic gist of the new system, but you wouldn’t use more than a sentence or two to do this, as the «meat» of our analysis will be in the body of the proposal.
  6. Image titled Write a Problem Statement Step 6

    6

    Explain the benefits of the solution. Again, now that you’ve told your readers what should be done about the problem, it’s a very good idea to explain why this solution is a good idea.[4]
    Since businesses are always trying to increase their efficiency and earn more money, you’ll want to focus primarily on the financial impact of your solution — which expenses it will reduce, which new forms of revenue it will generate, and so on. You can also explain non-tangible benefits, like improved customer satisfaction, but your total explanation shouldn’t be too much longer than a few sentences to a paragraph.

    • In our example, you might briefly describe how our company could conceivably benefit from the money saved with our solution. A few sentences along these lines might work: «ABC Airlines stands to benefit substantially from the adoption of this new boarding program. For instance, the $146,000 in estimated yearly savings can be re-directed to new sources of revenue, such as expanding its selection of flights to high-demand markets. In addition, by being the first American airline to adopt this solution, ABC stands to gain considerable recognition as an industry trendsetter in the areas of value and convenience.»
  7. Image titled Write a Problem Statement Step 7

    7

    Conclude by summarizing the problem and solution. After you’ve presented the ideal vision for your company, identified the problem keeping you from achieving this ideal, and suggested a solution, you’re almost done. All that’s left to do is to conclude with a summary of your main arguments that allows you to transition easily into the main body of your proposal. There’s no need to make this conclusion any longer than it needs to be — try to state, in just a few sentences, the basic gist of what you’ve described in your problem statement and the approach you intend to take in the body of the article.

    • In our airline example, you might conclude like this: «Optimization of current boarding protocols or adoption of new, more-effective protocols is crucial for the continued competitiveness of the company. In this proposal, the alternative boarding protocols developed by Dr. Right are analyzed for their feasibility and steps for effective implementation are suggested.» This sums up the main point of the problem statement — that the current boarding procedure isn’t very good and that this new one is better — and tells the audience what to expect if they continue reading.
    • Be sure to mention the possible consequences if the solution isn’t implemented.[5]
  8. Image titled Write a Problem Statement Step 8

    8

    For academic work, don’t forget a thesis statement. When you have to write a problem statement for school, rather than for work, the process will be largely the same, but there may be extra items you’ll need to take into account to assure a good grade. For instance, many composition classes will require you to include a thesis statement in your problem statement. The thesis statement (sometimes just called the «thesis») is a single sentence that summarizes your entire argument, boiling it down to its bare essentials. A good thesis statement identifies both the problem and the solution as succinctly and clearly as possible.

    • For instance, let’s say you’re writing a paper on the problem of academic essay mills — companies that sell pre-written and/or custom works for students to purchase and turn in as their own work. As our thesis statement, you might use this sentence, which acknowledges the problem and the solution we’re about to propose: «The practice of buying academic essays, which undermines the learning process and gives an advantage to rich students, can be combated by providing professors with stronger digital analysis tools.»
    • Some classes explicitly require you to put your thesis sentence at a certain place in your problem statement (for instance, as the very first or very last sentence). Other times, you’ll have more freedom — check with your teacher if you’re not sure.
  9. Image titled Write a Problem Statement Step 9

    9

    Follow the same process for conceptual problems. Not all problem statements are going to be for documents dealing with practical, tangible problems. Some, especially in academics (and especially in the humanities), are going to deal with conceptual problems — problems that have to do with the way you think about abstract ideas. In these cases, you can still use the same basic problem statement framework to present the problem at hand (while obviously shifting away from a business focus). In other words, you’ll want to identify the problem (often, for conceptual problems, this will be that some idea is not well-understood), explain why the problem matters, explain how you plan to solve it, and sum up all of this in a conclusion.

    • For instance, let’s say that we’re asked to write a problem statement for a report on the importance of religious symbolism in The Brothers Karamazov by Fyodor Dostoevsky. In this case, our problem statement should identify some poorly-understood aspect of the religious symbolism in the novel, explain why this matters (for instance, you might say that by better understanding the religious symbolism in the novel, it’s possible to draw new insights from the book), and layout how you plan to support our argument.
  10. Advertisement

  1. Image titled Write a Problem Statement Step 10

    1

    Be concise. If there’s one thing to keep in mind when writing problem statements, it’s this. Problem statements shouldn’t be any longer than they need to be to accomplish their task of laying out the problem and its solution for the reader. No sentence should be wasted. Any sentence that doesn’t directly contribute to the problem statement’s goals should be removed. Use clear, direct language. Don’t get bogged down in minor details — problem statements should deal only with the essentials of your problem and solution. In general, keep your problem statement as short as possible without sacrificing its informativeness.

    • A problem statement is no place to add your own personal commentary or «flavor», as this makes the problem statement longer for no practical purpose. You may or may not have the opportunity to be more long-winded in the body of your document, depending on the seriousness of your topic and audience.
  2. Image titled Write a Problem Statement Step 11

    2

    Write to your audience. When making a problem statement, it’s important to remember that you’re writing for someone else, not for yourself. Different audiences will have different sets of knowledge, different reasons for reading, and different attitudes toward your problem, so try to keep your intended audience in mind as you write. You want your problem statement to be as clear and easy for your audience to understand as possible, which means you may need to change your tone, style, and diction from one audience to another. As you write, try to ask yourself questions like:

    • «Who, specifically, am I writing for?»
    • «Why am I addressing this audience?»
    • «Does this audience know all of the same terms and concepts as I do?»
    • «Does this audience share the same attitude as I do towards this problem?»
    • «Why should my audience care about this problem?»
  3. Image titled Write a Problem Statement Step 12

    3

    Don’t use jargon without defining it. As noted above, your problem statement should be written so that it’s as easy for your audience to understand as possible. This means that, unless you’re writing for a technical audience that is likely to be knowledgeable in the terminology of the field you’re writing about, you’ll want to avoid using technical jargon too heavily and to make sure that you define any pieces of jargon that you do use. Never make the assumption that your audience automatically has all of the technical knowledge that you do or you risk alienating them and losing readers as soon as they encounter terms and information they’re not familiar with.

    • For instance, if we’re writing for a board of highly-educated physicians, it may be OK to assume that they’ll know what the term «metacarpal» means. However, if we’re writing to an audience made up of both physicians and wealthy hospital investors who may or may not be medically trained, it’s a good idea to introduce the word «metacarpal» with its definition- the bone between the first two joints of the finger.
  4. Image titled Write a Problem Statement Step 13

    4

    Stick to a narrow, defined problem. The best problem statements aren’t sprawling, rambling pieces of writing. Instead, they’re focused on a single, easily-identified problem and its solution. Generally, narrow, defined topics are easier to write convincingly about than large, vague ones, so whenever possible, you’ll want to keep the scope of your problem statement (and thus the body of your document) well-focused. If this makes your problem statement (or the body of your document) short, this is usually a good thing (except in academic situations where you have minimum page limits for your assignment).

    • A good rule of thumb is to only address problems that you can definitively solve beyond a shadow of a doubt. If you’re not sure of a definitive solution that can solve your entire problem, you may want to narrow the scope of your project and change your problem statement to reflect this new focus.
    • To keep the scope of a problem statement under control, it can be helpful to wait until after completing the body of the document or proposal to write the problem statement. In this case, when you write your problem statement, you can use our actual document as a guideline so that you don’t have to guess about the ground you may cover when you write it.
  5. Image titled Write a Problem Statement Step 14

    5

    Remember the «five Ws». Problem statements should be as informative as possible in as few words as possible, but shouldn’t delve into minute details. If you’re ever in doubt of what to include in your problem statement, a smart idea is to try to answer the five Ws (who, what, where, when, and why), plus how. Addressing the five Ws gives your reader a good baseline level of knowledge to understand the problem and solution without treading into unnecessary levels of detail.

    • For instance, if you’re writing a problem statement to propose a new building development to your local city council, you might address the five Ws by explaining who the development would benefit, what the development would require, where the development should be, when construction should begin, and why the development is ultimately a smart idea for the city.
  6. Image titled Write a Problem Statement Step 15

    6

    Use a formal voice. Problem statements are almost always used for serious proposals and projects. Because of this, you’ll want to use a formal, dignified writing style (the same as the style hopefully used for the body of the document) in the problem statement. Keep your writing clear, plain, and direct. Don’t attempt to win your reader over by taking a friendly or casual tone in your problem statement. Don’t use humor or jokes. Don’t include pointless asides or anecdotes. Don’t use slang or colloquialisms. Good problem statements know that they have a job to accomplish and don’t waste any time or ink on unnecessary content.

    • The closest you can usually get to including purely «entertaining» content in academic writing in the humanities. Here, occasionally, it’s possible to encounter problem statements that begin with a quote or epigraph. Even in these cases, however, the quote has some bearing on the problem being discussed and the rest of the problem statement is written in a formal voice.
  7. Image titled Write a Problem Statement Step 16

    7

    Always proofread for errors. This is a must for all forms of serious writing — no first draft has ever existed that couldn’t have benefited from the careful eye of a good proofreader. When you finish your problem statement, give it a quick read. Does it seem to «flow» properly? Does it present its ideas coherently? Does it seem to be logically organized? If not, make these changes now. When you’re finally satisfied with the structure of your problem statement, double-check it for spelling, grammar, and formatting errors.

    • You’ll never regret re-reading your problem statement before you turn it in. Since, by its very nature, the problem statement is usually the first part of a proposal or report that someone will read, any errors here will be especially embarrassing for you and can even reflect negatively on your entire document.
  8. Advertisement

Add New Question

  • Question

    What is a problem statement?

    Joe Simmons

    Joe Simmons is a Corporate Trainer based in West Palm Beach, Florida. Joe specializes in operations management, leadership, learning and development, and employee training to help employees become high-performing teams. He holds a Bachelor’s degree in Marketing from The University of South Florida. Joe’s coaching has helped numerous organizations with employee retention, revenue growth, and team productivity.

    Joe Simmons

    Corporate Trainer

    Expert Answer

    A problem statement is a short, succinct explanation of a problem that a business is facing, along with a proposed solution to the said problem. Basically, problem statements help you describe an issue and offer a solution in a short format.

  • Question

    What are the 5 elements of a problem statement?

    Joe Simmons

    Joe Simmons is a Corporate Trainer based in West Palm Beach, Florida. Joe specializes in operations management, leadership, learning and development, and employee training to help employees become high-performing teams. He holds a Bachelor’s degree in Marketing from The University of South Florida. Joe’s coaching has helped numerous organizations with employee retention, revenue growth, and team productivity.

    Joe Simmons

    Corporate Trainer

    Expert Answer

    The first element would be the problem, and the second would be the solution. Then, you’d discuss the benefits of the solution, along with any potential consequences. As a final touch, explain both the urgency of the problem and the long-term consequences of not solving the problem quickly.

  • Question

    How do I write a problem statement?

    Community Answer

    Describe the problem, back it up with evidence and explain your solution.

See more answers

Ask a Question

200 characters left

Include your email address to get a message when this question is answered.

Submit

Advertisement

References

  1. Joe Simmons. Corporate Trainer. Expert Interview. 29 June 2021.
  2. Joe Simmons. Corporate Trainer. Expert Interview. 29 June 2021.
  3. Joe Simmons. Corporate Trainer. Expert Interview. 29 June 2021.
  4. Joe Simmons. Corporate Trainer. Expert Interview. 29 June 2021.
  5. Joe Simmons. Corporate Trainer. Expert Interview. 29 June 2021.
  6. http://www.personal.psu.edu/faculty/c/a/caw43/behrendwriting/problemstatements.html
  7. http://journals.lww.com/academicmedicine/fulltext/2001/09000/problem_statement,_conceptual_framework,_and.21.aspx

About This Article

Article SummaryX

The first thing you should do in a problem statement is to describe the ideal solution using words like «should.» Then, introduce the problem by using words like «Unfortunately» or «However,» followed by a clear 1-2 sentence description of what’s wrong. In order to emphasize why this problem is important, explain the financial cost the business will suffer if the problem goes unsolved, and back your statement up with data. For more advice on how to propose a solution, including how to explain your solution in concrete concepts, read on!

Did this summary help you?

Thanks to all authors for creating a page that has been read 3,576,409 times.

Reader Success Stories

  • Vitty Gee

    «I was working on my research proposal draft, and was challenged most with writing up a good research problem…» more

Did this article help you?

Одна из основных проблем в ИТ проектах — взаимопонимание двух миров: бизнеса и разработки. Одни хотят быстро и красиво, другие хотят получить исчерпывающее описание хотелки. Переговоры занимают много времени, но еще больше — исправление ошибок. Как эффективно выстроить процесс, рассказывает зам технического директора музыкального сервиса «Звук» Кирилл Ларин.

заместитель технического директора музыкального сервиса «Звук» Кирилл Ларин Ольга Соркина

Так как разработка (+тестирование) — самое дорогое звено в создании ИТ-решения, то необходимо экономить время разработчика любым способом.

Если задача поступает в разработку с неполным описанием, то есть в ней нет всех Use cases и Corner cases, то разработчик тратит массу времени на выяснение нюансов. Или не хочет вступать в полемику и делает все, опираясь на свою картину мира, по принципу “художник так видит”.

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

Решение

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

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

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

Сквозь слёзы и пот мы в Звуке сформировали стандарт, который позволяет получить 90% информации, необходимой для решения любой it-задачи.

Cтандарт постановки задач

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

Для этого заказчику необходимо описать следующие аспекты задачи:

  • Требование
  • Проблема, которую надо решить
  • Продуктовые требования
  • Технологические требования
  • User stories
  • Use cases
  • Corner cases

Рассмотрим подробно каждый аспект.

Требование

Для точного определения, что требуется сделать в постановке задачи используется принцип SMART:

  • Specifiс. Задача должна быть конкретной. Куда мы пойдем, чего мы хотим достичь?
  • Measurable. В чем должен измеряться результат и какой результат будет для нас хорошим
  • Attainable. Достижимые цели. Здесь мы проверяем, находятся ли наши цели в реальных пределах
  • Relevant. Все задачи должны относиться к бизнесу и должны вести к цели проекта
  • Time-bound. Обязательное ограничение во времени. Большие задачи надо стараться разбить на более мелкие

Проблема

Какую проблему заказчик пытается решить?

Продуктовые требования

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

Технологические требования

Какие технологические требования и ограничения предъявляет заказчик к функционалу?

User stories

Какая функциональность ожидается?

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

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

Структура user story

Текст самой US должен объяснять роль/действия пользователя в системе, его потребность и выгоду, которые пользователь получит после того как история случится.

Пример

Как, <роль>, я <что-то хочу получить>, <с такой-то целью>.

Важно:

  • Есть одна Роль
  • Есть одно действие
  • Есть одна ценность/влияние

US можно оценить по критериям INVEST:

  • Independent. Меньше зависимостей — легче планировать
  • Negotiable. Детали появляются в ходе обсуждений команды разработки и заказчика
  • Valuable. Измеримая история — какие метрики изменились
  • Estimable. Большая или расплывчатая история — невозможно точно оценить трудозатраты
  • Small. Небольшая история разрабатывается в рамках недели
  • Testable. Простой критерий готовности

Важно помнить, что:

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

Use cases

Какой сценарий необходимо пройти, чтобы достичь цель?

Что UC включают в себя:

  • Кто пользуется системой
  • Что пользователь хочет сделать
  • Какая у пользователя цель
  • Шаги к достижению цели
  • Как система реагирует на действия пользователя

Что UC не включают в себя:

  • Реализацию на специфическом языке (терминология и т.п.)
  • Информацию про интерфейсы

Из чего состоят UC

В зависимости от глубины и сложности того, что вы хотите или должны достичь, UC описывают комбинацию следующих элементов:

  • Актер — кто или что выполняет действие.
  • Предварительные условия — что должно быть/случиться до и после прохождения UC.
  • Триггер — какое-то событие, которое стало причиной запуска UC.
  • Главный успешный сценарий — прохождение UC по ожидаемому сценарию.
  • Альтернативный сценарий — вариации главного успешного сценария. Происходит, когда что-то пошло не так на системном уровне.

Как писать UC

Для написания UC используются следующие шаги:

  • Определить кто будет пользоваться системой.
  • Выбрать одного пользователя.
  • Определить, что этот пользователь будет делать с системой. Каждое действие станет UC.
  • Для каждого UC определить курс событий, когда этот пользователь использует систему.
  • Опишите основной курс в описании для UC. Опишите его с точки зрения того, что делает пользователь и что система делает в ответ, о чем пользователь должен знать.
  • Когда базовый курс описан, рассмотрите альтернативные курсы и добавьте их, чтобы «расширить» UC.
  • Ищите общие черты среди UC. Объедините их как UC одного курса.
  • Повторить шаги с 2 по 7 для всех пользователей.

Corner cases

Для того чтобы избежать непредвиденных сценариев в работе фичи, необходимо описать все возможные CC. По сути, CC отвечает на вопрос А что будет, если …? СС должны покрывать большинство вариантов и указывать на причины возникновения вариантов.

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

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

Пример

С теорией всё понятно, но как дело обстоит на практике? Разберем упрощенное описание задачи на примере сохранения настроек приложения.

Требование

Сохранять настройки приложения

Проблема

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

Продуктовые требования

Использовать распространенный UX для реализации решения

Технологические требования

Сохранять настройки приложения на серверной стороне в связке с данными пользователя

User story

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

Use cases

— Пользователь открывает приложение.

— Пользователь входит в учетную запись в приложении.

— Пользователь устанавливает настройки приложения.

— Система сохраняет настройки.

— Пользователь выходит из учетной записи в приложении.

— Пользователь входит в учетную запись в приложении (+ на другом устройстве).

— Система передает сохраненные настройки в приложение.

— Приложение отображает сохраненные настройки пользователя.

Corner case

Обеспечить обратную совместимость со старыми клиентами.

Как помочь новому стандарту прижиться

Первое. Объяснить команде боль. Как известно, если вы указываете причину внедрения, конверсия увеличивается.

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

Третье. При внедрении обязательно собрать обратную связь по стандарту. Ответить на все вопросы, внести корректировки. Тогда будет коллективный труд, порог вхождения ниже.

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

Пятое. Закрепить нововведения фактами в виде цифр — сравните с периодом до внедрения. Производительность увеличилась на столько-то, количество ошибок упало на столько-то.

Выводы и результаты

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

В «Звуке» после внедрения стандарта скорость и качество работы увеличилось в 2 раза. Мы получили положительные отзывы от всех участников команды и решили основную проблему.

Постановка задачи в ИТ-проектах

  • Денис Богданов

    Ведущий эксперт YouTube-канала «ЦифраБуква»

    12-летний опыт работы в IT в качестве разработчика, аналитика, руководителя проектов, методолога системного анализа

    Опыт работы в энергетике,
    разработке государственных информационных систем
    (контрольно-надзорные органы, образование),
    транспортной логистике

  • Михаил Максимов

    Резидент Клуба мышления Санкт-Петербурга
    Ведущий эксперт YouTube-канала «ЦифраБуква»

    Автор и ведущий курсов по архитектуре предприятия и
    управлению проектами в ВУЗах (СПб ГУТ, СПб ГУАП)

    Опыт в IT 5 лет в качестве аналитика,
    методолога бизнес/системного анализа

Выпускающие редакторы статьи — Анна Гасраталиева и Денис Бесков

Что такое постановка на реализацию в IT?

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

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

Место постановки на реализацию
в процессе создания IT-продукта

Постановка на реализацию (розовый блок на рисунке) выполняется в рамках проектирования (светло-зеленый) перед реализацией.

Процесс реализации ИТ-проекта от инициации идеи до внедрения и эксплуатации готового ИТ-решения

Техническое задание разрабатывается на этапах Инициации и Определения метода решения бизнес-задачи. Здесь мы говорим про выявление проблемы, сбор исходных требований, формирование какого-то запроса на решение этой проблемы.

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

Постановка описывает конкретную функцию, модуль, что-то максимально локализованное. Объектами постановки могут быть отдельные компоненты, модули или функции – в зависимости от того, как мы декомпозировали функциональную структуру системы/решения в техническом задании.

Зачем нужна постановка на реализацию?

Постановка помогает:

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

Кто пишет постановку на реализацию?

  1. Менеджер проекта / менеджер продукта
  2. Аналитик
  3. Тимлид разработки, например, когда аналитика на проекте нет. Тогда менеджер верхнеуровнево описывает необходимые функции, а команда разработки сама пишет для себя постановки и задачи.

Кому нужна постановка на реализацию?

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

Основные разделы постановки на реализацию

Постановка на реализацию может содержать разделы:

  1. Контекст задачи
  2. Ключевые источники информации
  3. Заинтересованные стороны
  4. Критерии приемки результата
  5. Нефункциональные требования и ограничения
  6. Описание решения

В зависимости от проекта некоторые блоки могут быть опущены.

Разделы постановки на реализацию

Рассмотрим эти разделы на примере:

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

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

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

Раздел 1. Контекст задачи

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

Контекст задачи помогает:

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

Также данный раздел может содержать:

  1. Описание функций бизнес-языком
  2. Описание бизнес-процесса
  3. Бизнес-требования
  4. Перечень проблем бизнеса

Приведём пример описания контекста бизнес-языком:

Кейс: возможность предоставления клиенту плановых сроков доставки заказа

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

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

Дорабатываем систему Self Care в части отображения клиенту сроков доставки товара при оформлении заказа. Необходимо разработать АРМ для оператора call-центра, которому звонят с запросом сроков доставки.

Для чего этот бизнес-контекст разработчикам?

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

Пример из практики:

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

Итого, контекст задачи в постановке нужно описывать, потому что:

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

Раздел 2. Ключевые источники информации

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

Во-первых, это, конечно, глоссарий. Он необходим, чтобы заказчик, бизнес и команда оперировали одними и теми же согласованными терминами. Глоссарий должен быть приложен как один из источников информации.

Другие примеры ключевых источников информации:

  • Описание внешнего или ранее реализованного API (например, API компании-перевозчика). Разработчик не должен сам искать в интернете какую-то версию, т.к. она может оказаться не последней и не согласована с архитектором.
  • HLD (high-level design, описание архитектуры)
  • Стандарты заказчика, если речь идет про передачу листинг кода, а также когда есть свои определенные стандарты его оформления
  • Ссылка на памятку по чтению постановки. В некоторых случаях формат постановки может быть достаточно объемным и в нем могут использоваться артефакты, которые не всегда будут понятны человеку со стороны (или даже разработчику команды, который может воспринять постановку неправильно). Поэтому ссылка, например, на соглашение о моделировании вполне может быть источником информации.

Раздел 3. Заинтересованные стороны

Заинтересованные стороны (далее ЗС) — это перечень людей, которые будут влиять на принятие решений и от которых зависит успех реализации.

Чем помогает перечень заинтересованных лиц:

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

Роли заинтересованных сторон

Разница между проектными ролями и бизнес-ролями ЗС

Существуют разные роли, в которых выступают заинтересованные стороны по отношению к постановке. Например, бизнес-роли и проектные роли.

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

Например, у нас есть директор по развитию. На проекте он является куратором (улаживает какие-то вопросы и проблемы) — это его проектная роль. В качестве бизнес-роли он никем не выступает (строка №1).

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

Но как у человека этой области бизнеса у него есть компетенции, которые позволяют ему выступать от лица менеджера по работе с клиентами. То есть директор по взаимодействию с подрядчиками может грамотно сформулировать требование от лица менеджера, понимает, как менеджер работает, может ответить на все необходимые вопросы — это бизнес-роль (строка №2).

Маркетолог также может иметь и проектную, и бизнес роль. Т.к. маркетолог смотрит на то, как готовым продуктом будут пользоваться, то можно сказать, что он является клиентом компании и может диктовать требования от имени клиентов компании — это его бизнес-роль (строка №2).

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

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

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

Раздел 4. Критерии приемки результатов. Уровень детализации критериев приемки

Критерии приемки результатов — критерии, выполнение которых может говорить о том, что решение реализовано (definition of done постановки).

В широком смысле критериями приемки могут выступать:

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

Чем помогают критерии приемки:

  • дают понимание границ реализации,
  • обеспечивают полноту реализации,
  • выступают чек-листом приемки (аналитиком при авторском надзоре и заказчиком)

Примеры требований, которые могут служить критериями приемки:

  1. Необходимо учитывать время технологических операций по сбору заказа, хранению и транспортировке с производства до терминалов компаний-перевозчиков.
  2. Информация по срокам доставки конкретных компаний – перевозчиков должна рассчитываться в момент оформления заказа
  3. Перечень доступных для выбора компаний-перевозчиков должен формироваться с учетом возможности доставки компанией-перевозчиком по указанному адресу доставки

Раздел 5. НФТ и ограничения решения

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

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

К наиболее важным требованиям относятся:

  • производительность (использование в нескольких филиалах) ,
  • доступность (24/7),
  • масштабируемость (количество сотрудников).

Необходимо также учитывать:

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

Примеры НФТ и ограничений:

  1. Время расчета срока не должно превышать 1 секунду
  2. Необходимо предусмотреть возможность подключения в дальнейшем неограниченного количества компаний — перевозчиков
  3. Сервис расчета сроков должен быть доступен 24/7
  4. Расчет срока возможен только при online-доступности

сервиса предоставления информации о сроках конкретной компании-перевозчика

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

Раздел 6. Описание решения

Описание решения — это основная часть постановки, описывающая способ и границы реализации

Может содержать:

  • Сценарии использования (UseCase)
  • Информационные модели
  • Статусные модели
  • Алгоритмы
  • Макеты интерфейсов (UX/UI)
  • Компонентные схемы
  • Описание интеграций

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

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

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

При определении объема документирования важно:

  1. Включать только необходимый набор артефактов.
  2. Разделять постановку и документирование ИТ-решения.

Постановка отвечает на вопрос «что нужно сделать?», а техническая документация — «как это сделано / как это работает?». Стоит заметить, что грамотно сформированная классификация постановок в терминах UML может стать частью документирования. Это может помочь, когда на проекте отсутствует отдельный процесс документирования.

Конкретика

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

Команда

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

Переиспользование артефактов

Чтобы была возможность переиспользовать артефакты, необходимо подумать об их:

  1. Кодировании
  2. Классификации
  3. Хранении и обеспечении быстрого доступа
  4. Доступности для модификации и совместной работы
  5. Версионировании (т.к. видоизмененный в новой постановке артефакт, при отсутствии версионирования, не позволит доработать предыдущую версию артефакта по замечаниям от разработчика, например)

Счастливая команда – залог успеха

Счастливый менеджер понимает, что:

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

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

Счастливые тестировщики понимают, какие есть пользовательские сценарии использования продукта, внутренних алгоритмов

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

Как понять, какие разделы постановки нужны?

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

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

Матрица состава разделов постановки

Матрица состава блоков постановки

Если команда имеет опыт и экспертов в предметной области, то для выполнения простой задачи ей будет достаточно:

  • контекста задачи,
  • ключевых источников,
  • заинтересованных сторон,
  • НФТ.

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

А для неопытной команды будут необходимы все разделы.

Баланс в команде может достигается за счет сочетания опытной команды и неопытного аналитика или наоборот, опытного аналитика и неопытной команды.

Внедрение нового формата постановки

При внедрении нового формата необходимо подумать о том, что:

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

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

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

  • Вопрос:

    Как должен выглядеть шаблон постановок и ТЗ?

    Ответ:

    Шаблоны ТЗ — ГОСТовский шаблон (в ГОСТ есть перечень разделов, которые могут входить в ТЗ). Приходите на

    курс

    , там подробно разбираем шаблон ТЗ.

    Шаблон постановки может состоять из 3х основных частей:

    • заголовочная (общее описание, термины и определения, ссылки),
    • раздел для заказчика (критерии приёмки, бизнес-контекст),
    • раздел для разработчиков (НФТ, описание постановки).
  • Вопрос:

    В чем разница между постановкой задачи и описанием постановки задачи?

    Ответ:

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

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

  • Вопрос:

    Какие наиболее удобные средства ПО для ведения/написания постановки?

    Ответ:

    Если речь идет непосредственно о самих артефактах, то необходим Sparx Enterprise Architect, в котором можно будет этот артефакт спроектировать и нарисовать.

    Это могут быть как простые инструменты без репозитория самих элементов: visio, плагины для Confluence, онлайн-инструменты. Так и более сложные, например Sparx, где есть свой репозиторий, версионирование и возможность совместной работы.

    В части оформления документа можно использовать любое ПО, которое имеет возможность экспорта. Например, Confluence или Word.

  • Вопрос:

    Как лучше оформлять change request (запросы на изменения)?

    Ответ:

    Если инициатором изменений является заказчик, то сперва вносятся изменения в ТЗ и согласовываются с заказчиком, только после этого вносятся изменения в постановки разработчикам.

    Если инициатором изменения является сама команда разработки, тогда:

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

    В некоторых случаях также можно использовать формат «информирования» вместо «согласования».

  • Вопрос:

    Есть ли шаблоны постановки задач? Отличаются ли эти шаблоны для Backend и Frontend?

    Ответ:

    Если говорить про набор артефактов, то, например, для Backend макеты UI не будут полезны, также, как и базы данных для Frontend.

    О глобальном различии шаблонов говорить не приходится, т.к. имеет место одна общая постановка, которая логически разбита на компоненты (в данном случае Backend и Frontend), а артефакты будут сгруппированы внутри.

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

  • Вопрос:

    Стоит ли ставить на команду ограничения по времени на обработку одного запроса? Например, на анализ не более 24 часов

    Ответ:

    Жесткие ограничения — это плохо. Однако, стоит обратить внимание на декомпозицию и не тратить на 1 задачу более недели.

  • Вопрос:

    Jira или Confluence?

    Ответ:

    Jira

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

    Confluence

     — контент-менеджмент, он как раз позволяет писать и грамотно оформлять постановку задачи.

  • Вопрос:

    Какой должен быть минимум в постановке опытного системного аналитика? Как аналитик может показать свою высокую компетенцию через постановку?

    Ответ:

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

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

  • Вопрос:

    Михаил, что за клуб мышления резидентом которого ты являешься?

    Ответ:

    Клуб мышления

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

  • Вопрос:

    Насколько важно вести документацию? Какие виды документации вы создавали ранее?

    Ответ:

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

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

  • Вопрос:

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

    Ответ:

    Вы можете использовать постановку в сравнении версий, т.е. в предыдущей версии постановки выделяете все вносимые изменения.

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

  • Вопрос:

    Постановка задач не равна user story?

    Ответ:

    User story — это формат сбора требований, а постановка — это описание решений, а не формат требований. User story может выступать в качестве описания бизнес-контекста. Также критерии приемки могут быть описаны в этом формате.

  • Вопрос:

    Как использовать Epic в Jira?

    Ответ:

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

  • Вопрос:

    Как тогда отслеживать в Jira все изменения в одном разделе на протяжении жизни системы?

    Ответ:

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

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

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

    Всегда имеет место декомпозиция продуктов и работ, которая синхронизирована с Jira или Confluence (там, где лежат постановки). Если различные функции представлены в виде компонентов, эпиков и задач в Jira, то, скорее всего, есть какая-то похожая структура в базе знаний, в пространстве в Confluence, в виде папок на Google-диске. И все эти изменения мапятся.

Подписаться на новые статьи

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