Постановка задачи при создании программ это

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

7203 просмотров

Денис Гордиенко, генеральный директор Bright Mobile рассказывает о постановке задач для программистов.

Давайте вспомним, как обычно происходит, когда клиент обращается в студию или на фриланс. С его стороны обычно идёт некое описание конечной задачи в формате бизнес-процессов. Ко мне, чаще всего, обращаются по вопросам маркетплейсов и примерное описание выглядит так:

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

Джейсон Стетхем, Заказчик маркетплейса

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

Пример задачи на экран создания профиля:

Основы постановки задачи на разработку программ

Цель экрана: Дать исполнителю возможность размещаться в списке исполнителей и откликаться на заказы

Реализация: Пользователь заполняет анкету мастера и появляется в списке исполнителей. Поля, заполняемые исполнителем:

• Выбор категории
• Фото
• ФИО
• Номер телефона
• Краткая информация о себе
• Полная информация о себе

Кнопки сохранения и назад.

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

• Чёткая задача — при просмотре экрана сразу видно что сделано, а что нет.
• Лёгкость при разборе правок (если договаривались на дизайн на усмотрение программиста, то правки принимаются только к формату полей ввода и работе кнопок).
• Ну и дополнительная плюшка — не нужно разбираться в идее бизнеса клиента и нести ответственность за не оговоренные нюансы.

Итоговый результат правильно поставленной задачи

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

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

Чаще всего, вне зависимости от варианта процесс сводится к тому, что программист недооценил объём работ или клиент в процессе что-то поменял. Поднимается вопрос о доплате и далеко не всегда стороны приходят к компромиссу. Достаточно посмотреть FL.ru и количество проектов на нём в стиле «сделано на 90%, осталось доделать чуть-чуть».

Это было лирическое отступление в стиле «как всё плохо». Давайте теперь поговорим о том, как сделать хорошо.

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

Проектирование в достаточном объёме

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

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

Пришёл я к достаточно простому выводу, что двум сторонам нужен переводчик. Грубо говоря человек, который переведёт задание клиента с языка бизнес-процессов на язык поэкранной структуры первой версии приложения. С 10-го апреля по 10-е мая я сделал 15 проектов для приложений. Получилась вот такая статистика:

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

Итак, 8 проектов пошли в работу. На данном этапе завершён 1, 4 в середине пути, 3 в начале. Первые выводы которые сделал — документ позволяет чётко разграничить что входило в ТЗ, а что нет. То есть тот самый конфликт может возникнуть только в случае, когда какая-то из сторон захочет откровенно кинуть партнёра, но в 95% случаях, парой кликов, можно определить входила та или иная часть работ в оговоренную сумму или нет.

Структура документа

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

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

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

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

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

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

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

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

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

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

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

Постановка задачи программисту при разработке ПО

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

Подходящих товаров и услуг: 6

Мобильные приложения

Сопровождение разработки ПО

Создание и сопровождение разработки ПО специалистами нашей компании

Определение требований к ПО

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

ТЗ на программное обеспечение

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

ТЗ для мобильного приложения на iOS

iOS – одна из самых быстрорастущих операционных систем в мире. И только в России за последний год было продано около 4 миллио.

ТЗ для мобильного приложения на Android

Разработка приложений под Android не может вестись без детально проработанного технического задания.
Постановка задачи для программиста необходима при работе со следующими видами ПО:

• Создание корпоративных программ и платформ для компьютерных и мобильных устройств;
• Создание развлекательных приложений с подключенной монетизацией;
• Создание полноценных сервисов для всех видов ОС;
• Работа с аппаратным программным обеспечением.
• Постановка задачи программисту необходима перед созданием проекта для таких операционных систем, как Windows, MacOS, iOS, Android (компьютерные и мобильные ОС, соответственно).

Какие этапы описываются в поставленной задаче

Постановка задачи в программировании описывает три ключевых этапа работы специалиста:

1. Подготовка и описание проекта. Это теоретическая часть работы компьютерного программиста, которая основывается на пожеланиях заказчика, на маркетинговых исследованиях, на анализе конкурентов. Предварительно проводятся консультации относительно предполагаемой структуры ПО и оформления.
2. Составление проекта. На этом этапе разработчик учитывает описанные условия и требования в предоставленном техническом задании, после чего выстраивает структуру, прописывает ключевые формулы, использует коды, шаблонные макеты дизайна.
3. Алгоритмизация. Вспомогательный этап, который нередко проводится для анализа и проверки кодов, структуры будущего приложения.
4. Программирование. Эта стадия выполнения проекта по заранее поставленной задаче предполагает написание программных кодов и создание web-дизайна, подключение монетизации.
5. Препарация. Заключительный этап работы с проектами, который предполагает перенос готовой программы на носители или в торговую платформу (например, в Play Market)

Почему необходимо обратиться к профессионалам для постановки задачи программистам.

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

Используйте для связи наши контакты

Сотрудничаем преимущественно со странами: Россия, Беларусь, Украина, Казахстан.

• Время работы: Пн. — пт. 08:00-16- 00; Сб. 10:00-15:00
• Телефон: +375 29 693 8720
• Email:
• Telegram: tzprofi
• Skype: masssem

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

Держим под контролем все этапы разработки, от бизнес-аналитики до сдачи проекта подрядчиками.

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

Как ставить задачи разработчикам и не только. Why, What, DOD как понятный вариант SMART

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

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

Много букв, согласен. Раньше у меня в голове почему-то это все никак не могло уложиться в голове и стать привычкой при постановке задач, но потом я посмотрел выступление Александра Афенова Трудно быть Колей: теория и практика knowledge sharing в Lamoda и все встало на свои места.

В тексте должна быть картинка 😉 https://www.proofhub.com/wp-content/uploads/2019/11/The-16-Best-Kanban-Apps-for-Increased-Productivity-in-2020.jpg

Короче, есть вариант попроще SMART, с которым вполне можно успешно и не затратно по времени работать. Его как по мне проще запомнить и он понятнее, хотя суть вообще не меняется. У нас в команде мы уже взяли его на вооружение и я вижу отличные результаты — задачи стали сильно понятнее. Даже когда к задаче возвращаешься через время она не вызывает дискомфорт в плане того, что ты вне контекста и забыл что-то, что надо бы помнить для этой задачи.

Why, What, DOD

В любой задаче в описании должны быть заполнены следующие блоки:

Why (почему мы хотим сделать задачу)
What (что именно хотим сделать)
DOD (definition of done) список критериев успешности выполнения. Именно список, а не «проза» в виде простыни связанных предложений.

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

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

Epic: Перевод UI на ReactJS

Why : Поддержка LTS версии AngularJS кончается 21 декабря 2021 года, у нас весь проект написан на нем и проект имеет большую кодовую базу. Если мы не перейдем на другой фреймворк, то рискуем полной или частичной неработоспособностью нашего сервиса из-за обновлений браузеров, которые могут что-то непоправимо сломать. Нужно уже сейчас переходить на новый UI фреймворк, так как это очень трудоемкий процесс и нам нужен запас по времени. https://docs.angularjs.org/misc/version-support-status

What : Сейчас самым разумным видится перевод на React ввиду его гибкости, удобству и популярности у разработчиков, что поможет проще искать людей, а так же наличию гораздо большего количества готовых компонентов, по сравнению с Angular (2+).

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

Задача: Сделать прототип кода, который позволит подключать react компоненты в ui для постепенного переписывания на ui react

Why : У нас много кода для ui, мы не можем остановиться и разрабатывать его «с нуля» на react

What : Надо найти рабочее простое решение для того, чтобы уже сейчас можно было подключать простые компоненты интерфейса на reactjs

• Решение может не включать поддержку рендеринга angularjs компонентов в новых реакт компонентах (React -> AngularJs -> React).
• на react должен быть переведен компонент me-input text и там должна работать валидация и отключение валидации при рендере опционального lego
• компонент проверен рендерингом в me-lego-list
• вывод информации о пользователе в верхнем меню переведен на react
• angular 2 bootstrap отключен (так как если это не сделать, то мы очень сильно добавим времени на старт приложения и объем загружаемого кода)

Очень надеюсь, что вы уловите суть — вся техническая требуха в DOD по пунктам, а не сплошным монолитным текстом. Why, What жестко разделены и отвечает каждый за свое. Прям принцип единой ответственности в деле 😉

Пример

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

Текст задачи: «Вывести красную кнопку Купить справа от названия товара.»

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

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

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

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

Название задачи : Вывести дополнительную кнопку Купить на странице товара справа от названия товара

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

What : Справа от названия товара вывести стандартную красную кнопку «Купить», которая бы открывала стандартное модальное окно начала покупки.

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

+ Приложить к задаче ссылки и скриншоты с вебвизора на отчет по проблеме

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

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

А на этом всё, спасибо за внимание!

Подписывайтесь на канал , ставьте лайки, оставляйте комментарии — это помогает продвижению в Дзене.

#тимлид #teamlead #разработка #management #jira #постановка целей #постановка задач

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