Кейс из практики. Нам доверили сделать приложение для криптокошелька
Broex. Чтобы приступить к разработке, нужно было быстро разобраться в мире крипты. Клиент пришел к нам с готовой веб-версией продукта, а вот с мобильным приложением не задалось. Нам предстояло зарелизить кросс-платформенное приложение, чтобы сразу выйти в App Store и Google Play, причем используя бэкенд, который писали не мы.
Для работы с блокчейном и криптовалютой мало уметь хорошо разрабатывать приложения, в этом нужно разбираться глубже. Понимать, как происходит покупка, обмен, перевод и вывод криптовалюты. И не забыть про округления, подсчет баланса и комиссию. В общем, изучать тему нам пришлось максимально подробно. В ином случае мы не смогли бы работать с бэком заказчика и обеспечить для пользователей удобный и безопасный флоу.
Блин, как к людям приходят эти гениальные идеи стартапов? То холодильники, то ремонт в Дубаях…
А как можно посчитать все риски до старта проекта? Не предугадаешь ведь, если кто-то из сотрудников, например, заболеет… Или речь о каких-то других рисках?
Прям все риски не получится просчитать и минимизировать:) Но хотя бы существенную часть получится.
Мы это делаем так:
1. С командой в рамках часа накидываем любые идеи, где и что может пойти не так. Сюда попадают как больничные или смены тиммейтов по какой-то причине, так и проблемы с интеграциями сторонних сервисов или особенности тестирования продукта.
2. Дальше проектный менеджер и тимлид оценивают разрушительность последствий и вероятность каждого риска. Так мы определяем, что вероятнее пойдет не так, и что больше всего повлияет на проект — на предотвращении этого надо будет сфокусироваться.
3. В итоге составляем план по предотвращению наступления риска и план отходной — что будем делать, если риск все же наступил.
У вас много рассказано про превентивные меры. Ну а что например делать, если кто-то все-таки поругался?
Если кто-то начинает ругаться, не стоит бояться. Это значит, что команда сделала первый шаг к формированию внутрикомандных правил =)
На этом этапе важно сделать 2 вещи:
1. Помочь ребятам в моменте решить проблему: выслушать обе стороны и прийти к компромиссу.
2. А дальше важно выявить правило/урок на будущее, чтобы подобные ситуации больше не возникали.
Например, тестировщик не так или не туда перетаскивал карточки в Jira, а это бесило разработчика. Первое — мирим разработчика и тестировщика, говорим разработчику, что тестировщик не из злых намерений это делал =) Второе — фиксируем и доносим до команды тестировщиков следующее: «чтобы разработчики не злились, дорогие тестировщики, перетаскивайте карточки вот так».
Интересно, но как участники проекта будут больше общаться, если по сути каждый из них сидит над своей задачей, а видятся они раз в 1–2 недели?
Если инхаус и аутсорс командам нужен общий созвон только один раз в 1-2 недели — это же отлично =) Никто не отвлекается от работы, времени на обсуждения уходит мало, а результат делается.
На нашей практике так происходит очень редко. Чаще на небольших проектах с логикой средней сложности. Там основная коммуникация идет на старте. В случае если же проект сложный, неизбежно будет больше коммуникации.