В этой статье мы расскажем, как гибкие методы управления проектами могут сэкономить время и деньги, а также помогут создать актуальное мобильное приложение, не устаревшее на момент запуска.
Все мы имеем различный жизненный, профессиональный и социальный опыт. Поэтому неудивительно, что у людей зачастую возникают разногласия и недопонимания.
А можно ли этого избежать в бизнес-процессах?
Разбираемся на примере разработки мобильного приложения, посмотрим какие инструменты работают лучше. Ведь согласитесь, не хотелось бы выложить несколько миллионов рублей, а потом получить не то, что вы хотели.
На первый взгляд кажется, можно же написать исчерпывающее техническое задание (ТЗ) разработчикам и все будет «как надо». Но все может быть не так гладко даже с ТЗ и вот почему👇
Работа по ТЗ относится к традиционным методам управления проектами. Каскадная модель (waterfall) была представлена Уинстоном Ройсом ещё в 1970 году. В его основе лежит логическая последовательность шагов, которые должны быть предприняты на протяжении жизненного цикла разработки программного продукта. Каждый этап согласовывается, документируется и передаётся дальше. Вся работа идет последовательно от этапа к этапу. Пока предыдущий этап полностью не завершен, следующий начинать запрещено. Продукты, разработанные по данной модели, могут иметь недочеты, и к сожалению, о некоторых из них станет известно лишь в конце проекта.
Главная сложность — невозможность предусмотреть в ТЗ все мелочи.
В процессе создания технического задания (ТЗ) для мобильного приложения, необходимо учесть множество деталей и требований. Однако, предсказать все нюансы: идеально проработать анимацию, переходы, нестандартные сценарии – довольно сложно. А еще не так уж и просто корректно и детально описать все эти моменты в ТЗ. Нужно избежать логических противоречий, чтобы обеспечить однозначное понимание для команды разработчиков.
Однако, несмотря на все усилия, конечное приложение может отличаться от изначальной задумки заказчика, так как понятия и формулировки в ТЗ часто бывают общими и не всегда точными, а некоторые важные детали могут быть упущены. Разработчики, в свою очередь, могут интерпретировать и реализовывать указанные в ТЗ требования по-своему.
Грустный пример: Вы получаете через 12 месяцев готовое приложение, а там продукты листаются нажатием на кнопку, а не свайпом в сторону. Вроде бы мелочь, но уже вы не в тренде.
Разработка ТЗ может занять много времени.
Иногда для этой задачи привлекают аналитика, который может потратить от одного до трех месяцев на создание такого документа. За это время, можно было бы уже реализовать до половины проекта, потратить средства на разработку, маркетинг и запуск приложения на рынке.
Как выстроить работу без ТЗ
Да, без ТЗ тоже можно. Методология разработки может быть жесткой, например, по каскадной модели, или гибкой.
Agile – это целое семейство гибких методологий управления проектами. Agile гораздо моложе, чем каскадная модель. Основные ее принципы сформулировали в 2001 году. Эта методология была разработана специально для IT-сферы, хотя сейчас применяется довольно широко и в других. Сам по себе Agile не является полноценным методом управления проектами, это скорее философия управления разработкой.
Вся суть Agile содержится в четырёх пунктах ее манифеста:
· Люди и их взаимодействие важнее процессов и инструментов проектного управления.
· Рабочее программное обеспечение важнее всеобъемлющей документации.
· Сотрудничество с клиентами важнее переговоров по контракту.
· Реагирование на изменения важнее следования плану.
Именно из-за последнего пункта семейство методологий Agile и называется гибким.
В Agile входит несколько методологий: Scrum, Scrumban, Kanban, Lean, XP, FDD, TDD, SoS, LeSS, SAFe, AgilePM. Все они соответствуют принципам Agile и различаются только отдельными инструментами и подходами к управлению.
Давайте подробнее разберем, как выстирается работа на примере Scrum методологии.
В Scrum весь проект разработки разбивается на короткие итерации (спринты). Спринт в Scrum — это короткий временной интервал, в течение которого команда выполняет заданный объем работы. Обычно это две-четыре недели. Внутри каждой итерации собрана серия задач: анализ, проектирование, непосредственно работа и тестирование. После каждой итерации команда анализирует результаты и определяет приоритеты для следующего цикла.
Scrum предписывает только три роли: владелец продукта, Scrum-мастер и команда разработчиков.
· Scrum-master выступает в качестве коуча команды и помогает оптимизировать работу.
· Собственник продукта или менеджер продукта представляет ключевую заинтересованную сторону в продукте. Он отвечает за приоритизацию задач.
· Команда включает разных сотрудников с нужными для разработки продукта навыками.
При планировании спринта владелец продукта ставит задачи и определяет их приоритетность. Команда определяет объемы работы, чтобы завершить запланированное в течение следующего спринта.
Между спринтами Scrum-master ежедневно организовывает короткие встречи (примерно по 15 минут), чтобы ответить на три вопроса:
· Что вы делали вчера?
· Что вы планируете делать сегодня?
· Есть ли какие-либо препятствия, которые мешают вам выполнять свою работу?
Отвечая на эти простые вопросы, команда быстро может выявить проблемы, которые требуют особого внимания и оптимизировать процесс работы.
И да, работа по Scrum предполагает активное участие заказчика на всех этапах разработки. Но в этом есть большой плюс, ведь в случае чего, можно сразу бить тревогу, если что-то не так или появилась новая идея. Например, часто бывает, смотришь прототипы экранов, да, нарисовано красиво, а когда начинаешь нажимать — оказывается неудобно. Применяя эту методологию, это легко исправить на стадии разработки, а не писать доп. соглашение к ТЗ и платить за правки.
Подытожим: Scrum методология позволяет запускать небольшие проекты за 3–5 месяца, а средние — за 10–12 месяцев. И это без переписываний и осмысливаний ТЗ, миллиарда уточнений и десятков совещаний на протяжении долгих месяцев.
А можно вообще без этих заморочек получить готовое мобильное приложение?
Да, в таком случаи вам нужно искать у вендоров тиражное решение.
Спойлер: у нас в АДС-Софт уже есть такое для страховых компаний.
Простыми словами тиражируемый программный продукт — это программа, которая в базовом варианте имеет весь необходимый функционал для закрытия задач клиентов. То есть вы получаете уже готовое приложение, которое можно заливать в Google Play и App Store.
Плюсы тиражного решения:
· быстрый запуск проекта
· фиксированная стоимость
· возможность ознакомиться со всем функционалом приложения до покупки
Тем самым вы сможете заранее убедиться, устраивает ли вас функционал и дизайн, а затем принять мотивированное решение.
Еще одним важным плюсом тиражного решения является поддержка и доступность обновлений. Это важно, потому что любые работы по устранению ошибок или доработкам влекут за собой дополнительные затрат. За тиражное приложение вы платите фиксированную стоимость, а расходы на его актуализацию несет вендор.