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

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

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

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

Все картинки в статье, кроме одной, – это потрясающие работы шведского художника Саймона Сталенхага http://www.simonstalenhag.se Одна картинка сделана на основе «Настенькиных комиксов»

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

АЛГОРИТМ ПОСТАНОВКИ ЗАДАЧ

ПОДГОТОВИТЕЛЬНЫЙ ЭТАП

Даже к постановке задачи НЕОБХОДИМО готовиться.

• Можно ли эту задачу вообще не выполнять?

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

• В зависимости от ответа выбираем тип/частоту контроля

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

• Кому нужно сообщить о том, что к ним придет сотрудник и ему нужно будет оказать содействие?
• Нужно ли кого-то переподчинить сотруднику?
• Где сотрудник может найти дополнительную информацию и есть ли она вообще?
• Какие задачи он уже выполняет или какие стоят в очереди?
• У сотрудника достаточно времени? (вы же не хотите, чтобы он перегорел или у него села батарейка?)
• Определить приоритет новой задачи относительно других задач.

ПОСТАНОВКА ЗАДАЧИ

На этом этапе беседуем с сотрудником.

• Коротко рассказываем, что нужно сделать.

• Делайте упор на «что», а не «как». Это очень унизительно, выслушивать с какой ноги нужно шагать, отправляясь на выполнение задания.

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

ТОП-9 советов как написать техническое задание? (ТЗ или техзадание за 9 шагов)

• Здесь помним не только про текущую нагрузку сотрудника и реальные сроки задачи, но и про закон Паркинсона: работа делается как минимум столько времени, сколько на нее выделено. Т.е. не стоит просить что-то сделать, не давая сроков вообще или давая слишком много времени.
• Не шутите, что сроки «вчера». Слишком часто это произносят всерьез.

• Т.е. отвечаем на вопрос «зачем вообще эта задача нужна с точки зрения отдела/бизнеса/стратегии». Поясняем, что выполнение этой задачи необходимо, чтобы выполнить другую. Иными словами, объясняем, каковы последствия успешного или неуспешного выполнения этой задачи.
• Сотрудник должен понимать:

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

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

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

• Мотивируем сотрудника

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

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

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

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

• Все остальное сотрудник должен делать самостоятельно.

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

• Как будешь выполнять (в общих чертах)?
• Повтори суть задачи своими словами

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

• Есть вопросы?
• Что тебе не хватает для успешного выполнения задачи?
• Есть ли конфликты с текущими делами?

• Увы, точно знать степень загруженности сотрудника нельзя

НЕСКОЛЬКО ОБЩИХ СОВЕТОВ

• Приучите сотрудников приходить с блокнотом и ручкой. Голова – плохая база данных.
• Вместо блокнота и устных распоряжений можно использовать системы постановки задач. Но там не позадаешь вопросы. Поэтому лучше писать туда задачу уже после общения с сотрудником.
• Даже простые задачи лучше ставить в системе управления проектами и задачами.
• Сразу после постановки задачи сотруднику необходимо в своем ежедневнике поставить заметку на дату ближайшей точки контроля. Сотрудник может быть сколь угодно ответственным. Но жизнь штука сложная, поэтому выполняйте свою работу – ставьте задачи, контролируйте прогресс и управляйте рисками. Вы же менеджер или кто?
• Предложенный алгоритм фактически содержит в себе более простой подход к постановке задач, который известен под аббревиатурой SMART. Смарт-подход описывает, какой должна быть правильно поставленная задача/цель. Каждый год я вклеиваю в новый ежедневник на первую страницу вот эту картинку:

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

ПОЧЕМУ ВСЕ-ТАКИ ЗАДАЧА НЕ ВЫПОЛНЕНА?

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

• Не умеет (зачем же ему поставили эту задачу, не обучив или не предоставив возможности учиться и ошибаться?)
• Не понял (ему поставили задачу плохо, сотрудник понял по-своему)
• Не может (ему не дали ресурсов или полномочий)

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

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

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

Источник: np0cmo-ma.livejournal.com

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

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

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

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

Если задача поступает в разработку с неполным описанием, то есть в ней нет всех 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. История должна выполняться без привязки к конкретным элементам.
• Каждая история должна содержать оценку.
• История должна иметь концовку — т.е. приводить к конкретному результату.
• История должна помещаться в итерацию.

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

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

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

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

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

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

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

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

Как писать UC

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

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

Corner cases

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Corner case

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

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

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

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

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

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

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

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

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

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

Источник: vc.ru

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

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

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

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

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

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

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

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

Иллюзия фокусировки

Дэниел Канеман писал:

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

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

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

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

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

Эффект фиксации

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

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

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

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

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

Выводы

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

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

Фото на обложке: unsplash.com

Источник: rb.ru