Ваша заявка получена!
Наш менеджер вскоре свяжется с Вами!

Напишите письмо
команде Rubedite

Я бы хотел поговорить о...
Размер файла слишком большой
Главная Блог Как ускорить разработку сайта или приложения? 16 жизненных советов

Как ускорить разработку сайта или приложения? 16 жизненных советов

Наш опыт быстрого выхода в релиз

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


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


Приятного чтения!


Скорость разработки = скорость получения результатов


Стартап - уже команда, а основатель - уже руководитель. Чтобы быстро вывести на рынок MVP, босс должен контролировать ход работ и действия сотрудников, не влезая в технические детали. А если что-то идет не так - должен принимать управленческие решения.


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


Также мы не стали использовать иноязычные термины и описывать тонкости Scrum разработки, принятые в нашей команде. Желающим узнать, как с помощью этой методики можно форсировать работу команды, рекомендуем познакомиться с этими статьями: Всё что вам нужно знать о Scrum за 6 минут, оценка стоимости методом Фибоначчи.


Наши советы повышают скорость разработки на всех этапах проекта - от планирования до выхода на продакшн:


  1. Верхнеуровневое планирование - определяем суть проекта и его цели - что мы делаем в проекте и для чего, какие ожидаем результаты. 
  2. Детальное планирование - составляем список задач для реализации проекта и оцениваем время на их выполнение. 
  3. Разработка и внедрение - непосредственная реализация проекта - разрабатываем и тестируем продукт, завершаем этап празднованием первого релиза.

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



(источник: noctambule.info)

Верхнеуровневое планирование. Визируем истинные цели, отбрасываем ложные


1. Вижу цель - не вижу преград.

Цели проекта надо сформулировать так, чтобы их можно было оценить. Абстрактные фразы "улучшить" и "повысить" должны быть под запретом. Фраза "улучшить X, чтобы он стал более масштабируемым и эффективным" не годится - эти понятия невозможно выразить в цифрах. Вариант "улучшить X, добавив модульное тестирование, поддержку 20 тыс. запросов в секунду, и уменьшив среднюю задержку пользователей до <=200мс" - более правильный.

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

  • обязательно сделать (без них никак нельзя);

  • желательно сделать (пойдет на пользу проекту);

  • можно сделать (а можно и не делать);


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


2. Едим слона по частям.

Разделите проект на крупные фазы. Уменьшите объем работ на каждой фазе проекта:

  • Зафиксируйте промежуточные результаты на каждой фазе;

  • Договоритесь о плане выпуска релизов и доработок.


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


3. Побеждать без риска - побеждать без славы.


Оцените риски проекта, снижайте шансы провала для самых критичных работ:


  • Начните делать самые рискованные части, чтобы иметь запас времени;

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

  • Используйте заглушки и симуляторы интерфейсов, если смежные системы еще не готовы


4. Первым делом, первым делом - эффективность.


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


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



(источник: depositphotos.com)

Детальное планирование. Отмеряем, отмечаем, отрезаем


5. По задаче на каждый день.


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


6. Каждому этапу - свой срок.


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


7. Пунктуальность - вежливость зануд.


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


8. Запас беды не чинит.


Заложите дополнительное время на реализацию проекта. Начинающим руководителям мы рекомендуем увеличить итоговые оценки в 1,5 раза. С опытом вы научитесь более точно планировать сроки. Причины задержек:


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

  • Во время работы над проектом могут возникать неожиданности: не линкуется сторонняя библиотека, нужно переписать старую процедуру или сделать рефакторинг кода. Может потребоваться дополнительная отладка или повторное тестирование.


9. Правильно сформулированный вопрос - половина ответа.

А детальное описание задачи - 90% ее успешной реализации.


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


Часто крупную задачу можно разделить на более мелкие. Привлеките к декомпозиции руководителя группы разработки (team lead), квалифицированного бизнес-аналитика или команду Rubedite (это была минутка саморекламы).


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


10. Цена, качество или скорость?


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


11. И опыт, сын ошибок трудных.


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


12. Два сапога - не пара.


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


13. Совершенство недостижимо, а ресурсы - конечны.


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



Разработка и внедрение. Контролируем, оцениваем, решаем


14. Кто часто проверяет, ничего не теряет.


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


15. План - инструмент руководителя.


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


16. Все прошло, как огнем прожгло.

Или проект выходит за сроки.


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


  • Оценить и предложить новые сроки завершения проекта;
  • Выпустить продукт в срок, но без части функций;

  • Приостановить проект, зафиксировав убытки.


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


Обращайтесь!