У старой басни Эзопа о черепахе и зайце есть несколько хороших уроков, которые относятся к приоритизации при разработке приложений. Тот, кто медлителен и устойчив, побеждает в гонке. Другое состоит в том, что, несмотря на биологическое преимущество, которым заяц обладал над своим противником, его дерзкое высокомерие и плохие решения приводят к его провалу.
Мораль в истории не может быть правдивее в бизнесе, будь то рост компании или проекты в меньших масштабах, такие как разработка приложений. Рост - это хорошо, но без инфраструктуры для удовлетворения дополнительных требований, которые это создает для организации, он вместо этого превращается в катализатор краха. Слишком быстрое продвижение по проекту вызывает свои собственные уникальные проблемы, поэтому расстановка приоритетов является ключом к успешному результату.
Существует большая разница в реальности того, что команда разработчиков приложений может достичь вопреки ожиданиям. Это походит на драму, которая идет прямо к видео-полкам - между двумя людьми внезапно расцветает величественная любовь, кто-то бросает мяч с ожиданиями, происходит выпад, а затем - счастливое воссоединение. Это фильм, в котором вы засыпаете, но не удосуживаетесь закончить его, потому что это всего лишь одно большое клише.
При разработке программного обеспечения могут возникать такие же проблемы, когда не удается установить ожидания и границы. Отсутствие связи между всеми сторонами, а не только с директивами, установленными менеджерами по продуктам и ИТ-менеджерами, создает противоречия между различными командами.
Плохое общение между разработчиками, руководством, заинтересованными сторонами и другими командами может:
Создавайте сложные или невозможные сроки. Великие лидеры могут продать видение и рассказать всем о следующем проекте. Естественно, хорошие игроки команды чувствуют мотивацию и погружаются в процесс. Проблема, которую это может вызвать, заключается в том, что некоторые из них либо переоценивают свои возможности, либо слишком очарованы лидерами, чтобы думать о сроках, которые они получают. Напряженность возрастет, когда крайние сроки будут перенесены или не соблюдены, и команда может потерять мотивацию.
Увеличьте риск и затраты. Задержки в проекте могут не только снизить моральный дух, но и затраты могут также нанести урон. Без четкой оценки стоимости функций это может привести к плохим прогнозам и медленной окупаемости, что имеет долгосрочные последствия. Если нет четкого акцента на наиболее выполнимых функциях для первоначального запуска. Планирование определения минимально жизнеспособного продукта (MVP), который можно протестировать в реальном мире, поможет определить направление, позволяя разбить проект на управляемые сегменты.
Потерять пользовательскую базу . Если вы находитесь в процессе просмотра шоу на Netflix, но сервис не работает, что вы делаете? Большинство переключается на Hulu или какой-либо другой сервис. Если возникнет ощущение, что сервис постоянно отключается, многие в конечном итоге отменит свою подписку, пойдут к конкуренту и найдут другой способ посмотреть « Чужие вещи» . Если вам не удастся расставить приоритеты по обслуживанию, исправлению или устранению ошибок, пользователи будут разочарованы и будут искать альтернативное решение.
Обесценить ваш проект . Первый запуск не должен иметь все функции, которые вы собираетесь включить. Пытаясь втиснуть все сразу, все проблемы становятся гораздо более вероятными. Кроме того, когда запущенные функции не кажутся отточенными, пользователи могут не искать новые функции и могут отказаться от покупки премиальных функций. Отсюда финансовые прогнозы не будут соответствовать своей цели. Единственное, что может быть хуже этих трудных разговоров с инвесторами, - это сказать ребенку, что нужно отменить поездку в Диснейленд!
Чтобы не дать разработчикам выйти из ярости, продуктивно работать в команде и начать работу над проектом, есть несколько советов, которые следует учитывать при разработке стратегии. Убедись, что ты:
Разработайте дорожную карту через сотрудничество. Все должны быть на одной странице - хотя это и создает волнение, это полезно, но не позволяйте пыли, которая поднимает дискуссии в облаках. Откройте коммуникационные каналы между разработчиками, руководством и заинтересованными сторонами для создания результатов в реалистичные сроки. Воспользуйтесь преимуществами программного обеспечения, такого как Asana, или других решений для рабочих процессов, чтобы добавить свой план действий, поскольку это создает наглядность, позволяя членам команды координировать действия и выявлять проблемы, прежде чем они превратятся в существенные проблемы. Это поможет точно настроить приоритеты, а также позволит командам быстро устранить ошибки среди других болевых точек.
Расставьте приоритеты функций для MVP. Подумайте, какие функции необходимы для привлечения первоначальной базы пользователей, проанализировав потенциальную ценность . Посмотрите на продукты конкурентов и подумайте, что вы будете предлагать, улучшая существующий дизайн или привнося инновации на рынок. Выясните, что представляет наименьший риск, и используйте эти элементы в первом воплощении вашего программного обеспечения.
Определите структуру и протестируйте программное обеспечение с тщательным процессом обеспечения качества. Среди разработки функций будут проблемы, которые возникнут с кодом, лежащими в его основе зависимостями и, конечно же, «неизвестными неизвестными». К ним необходимо обратиться, чтобы обеспечить совместимость UI / UX в каждой точке установки, безопасность заблокирована и функции работают должным образом. Один из лучших способов сделать это подвиг с рамкой объективно КЛАССИФИЦИРУЙТЕ ошибки , как с высоким приоритет должен иметь приоритет над другими задачами, такими , как развитие новых возможностей.
Препятствия устраняются и сталкиваются рано. Когда возникает проблема, которая может привести к задержкам, ее следует обсудить как можно скорее. Лучше планировать такие проблемы, чтобы не было внезапной, дорогостоящей остановки процесса разработки. Убедитесь, что разработчики чувствуют себя комфортно, сообщая о проблемах, чтобы как можно скорее раскрыть их. Это позволяет всем поворачиваться и минимизировать - или, надеюсь, устранить! - любые негативные последствия.
Приспосабливайтесь к обратной связи и создавайте постепенно. Те, кто занимается розничной торговлей, могут утверждать, что фраза «клиент всегда прав» обоснованна - конечно, этот факт не всегда имеет место, но опыт потребителя и обратная связь необходимы, чтобы понять, как сделать улучшения. После запуска приложения проанализируйте, какие функции используются чаще всего. Следите за отзывами пользователей, чтобы узнать, что им нравится, а что нет. Используйте эту информацию для исправления или изменения функций, а также для планирования сроков развертывания новых функций.
Используйте аналитику в приложении, чтобы отслеживать, как люди используют приложение. Очень важно воспользоваться аналитическими решениями, такими как Firebase, MixPanel, Flurry, или пакетом по вашему выбору, чтобы определить, как пользователи взаимодействуют с приложением. Это дает пару преимуществ, таких как выявление проблемных областей, которые могут выходить за границы «традиционной» ошибки. Данные также показывают участие, которое полезно при определении и определении приоритетов новых функций во время следующего раунда разработки. Эти решения просты в развертывании практически для любых усилий, а также помогают разработчикам общаться, что позволяет командам быстро поворачивать и минимизировать - или, надеюсь, устранить! - любые негативные последствия.