Меню

Полезные практики по управлению разработкой

19 апреля директор по развитию Tados выступила на «Предпринимательской среде»

  • Начинайте с бизнес-плана и изучения потребностей целевой аудитории. Это сэкономит время и убережет от ошибок;
  • Не забывайте о потребностях рынка, любая компания работает ради получения прибыли;
  • Создание качественного продукта не завершается никогда, поэтому выстраивайте с заказчиками долгосрочные отношения. Для этого нужно улучшать продукт и бизнес заказчика, «подсаживая» его на услуги;
  • Держать руку на пульсе поможет подсчет Retention Rate. Он показывает, справляемся ли мы с удержанием клиентов, или нужны улучшения в работе с ними;
  • Опыт Tados показал, что для заказной enterprise-разработки лучше использовать подход Time&Material. Вы сможете разрабатывать продукты итерациями и получать оплату по факту. По-другому делать сложно, так как в процессе разработки даже заказчик открывает для себя много нового о бизнес-процессах компании;
  • Не приучайте заказчиков к доступности 24/7. Это изматывает команду, а отучить заказчика звонить и писать в нерабочее время сложно. Он воспринимает готовность помочь как должное;
  • Не допускайте ситуацию, когда от одного проекта зависит слишком многое. Думайте о рисках;
  • Если сложно подбирать достойных сотрудников, растите их. Tados регулярно устраивает IT-митапы.

26 апреля Carrot quest, Xsolla и Playkey провели встречу по управлению разработкой

Дмитрий Сергеев рассказал про применение Scrum.

  • Оценивать трудоемкость задач должна вся команда на планировании спринта. Оценивайте точно, так как на основании планов по выпуску определенной функциональности планируется развитие бизнеса;
  • Ошибки удобно делить на два вида: те, которые обнаружили в уже работающей функциональности и те, которые возникли при работе над новой. Первые поступают на приоритезацию Product Owner’у, вторые исправляются при стабилизации релиза;
  • Закладывайте время на непредвиденные задачи;
  • На демо приглашайте всех, кто работает над продуктом независимо от специализации. Программисты начнут понимать проблемы пользователей, а продажники будут лучше разбираться в продукте;
  • Мини-ретроспективы можно проводить после каждого спринта. На них стоит вкратце подвести итоги, перечислить, что получилось сделать, а что нет. Как часто проводить масштабные ретроспективы, должна решить команда. На них выписываются проблемы, предлагаются улучшения и выбираются те, которые команда внедрит до следующей ретроспективы.

Антон Жвакин поделился опытом выстраивания процессов в большой компании.

  • Меняя структуры и процессы, начинайте с пилотной команды, экспериментируйте на ней. Так вы быстрее придете к оптимальному варианту и затратите меньше ресурсов;
  • Работайте с людьми, выстраивайте доверительные отношения, разбирайтесь в их проблемах и делегируйте;
  • Полезные книги по управлению проектами: Богданов В. «Управление проектами» и Беркун С. «Искусство управления IT-проектами».

Алексей Лыков вызвал дискуссию рассказом о работе без дедлайнов.

  • Автотесты финансово оправданы только на устоявшемся продукте;
  • Когда не все ресурсы участвуют в проекте в режиме фултайм, а делятся с другими командами, удобно работать по Kanban. Это позволяет не строить строгий календарный план и спринты;
  • Product Owner должен поддерживать Backlog в актуальном состоянии. Приоритетные задачи должны быть отсортированы, оценены и готовы к тому, чтобы команда взяла их в работу;
  • Если команда работает без строгих дедлайнов, необходима высокая самоорганизация и отказ от излишнего перфекционизма. В противном случае можно ничего не выпустить, ведь переписывать и рефакторить можно вечно.

27 апреля ребята из RealtimeBoard провели встречу по обмену опытом в QA

  • Закладывайте 30% спринта на регрессионное тестирование и исправления ошибок;
  • Меняйте сценарии для регрессионного тестирования, так как с каждым прогоном эффективность падает;
  • Скрам делает тестирование удобнее, так как подразумевает работу над юзер стори. Тестирование полноценной юзер стори снижает вероятность упущений;
  • Тестировщик начинает работать с начала спринта. Он знает, какие юзер стори будут реализованы и готовится к тестированию: изучает, пишет тест-кейсы;
  • Тестировщик полезен и на этапе проектирования. Он добавит варианты использования и задаст полезные вопросы, чтобы команда ничего не упустила;
  • Проводите эксперименты, выделяйте время на исследовательские инженерные задачи и постоянно меняйтесь, чтобы повышать эффективность работы;
  • Задача сделана только тогда, когда вылита на прод. Если кто-то что-то не успел, это провал всей команды;
  • Автоматизируйте тестирование той части функционала, где это оправдано с финансовой точки зрения;
  • Автотесты хороши тем, что находят то, чего может не найти человек;
  • В рамках каждого регрессионного тестирования не забывайте о тестировании на мобильных версиях;
  • Тестировать мобильные версии эффективнее в условиях, приближенных к пользовательским. Тестируйте на мобильных устройствах, идя по улице или сидя на пуфике;
  • Изучайте, как выглядят элементы в мобильных версиях, легко ли по ним попадать, удобно ли вводить текст.
Полезные практики по управлению разработкой
Средняя оценка 5 Проголосовало 1