➡️Сегодня предлагаю обсудить проблему перерасхода ресурсов на проекте, и как его избежать.
1️⃣Цели. Начнём с основы - когда вы только начали разработку MVP, донесите всей команде основные цели.
2️⃣Приоритизация. Мои подписчики наверняка прекрасно знают, что это и как это работает. Сосредоточьтесь главным образом на том, ради чего которого и затевалось это MVP.
3️⃣Демо - как можно чаще. Вам нужно быть и с заказчиком (в первую очередь) и с пользователями — on the same page.
4️⃣Жесткие дедлайны - все мы - менеджеры, немного драконы😁 Установите жёсткие ограничения на время и другие ресурсы на MVP.
5️⃣Метрики. До старта согласуйте метрики успешности MVP с заказчиком. Это не даст разрастись бэклогу mvp, а ещё поможет сосредоточиться на достижении четких результатов.
6️⃣Минимум документации - не надо убивать время на документирование. Да, важно и нужно самое-критичное фиксировать. А в остальном от вас ждут результат mvp - продукт, а не бумажки. Их можно сделать в конце или параллельно. В процессе разработки MVP меняется - вы просто убьете время на документирование.
7️⃣Техдолг. Я всегда была и есть за качество. Но не стремитесь к идеальному коду на этапе MVP, находите баланс, чтобы быстрее получить продукт и получить пользовательскую обратную связь. Берем в работу то, что архиважно, что скажется на архитекттуре или приниципиально важных вещах в части разработки, качества и поддержки(!)
8️⃣Ганта - нельзя пилить MVP без роадмапа! У вас короткий срок и нужно отдать жизнеспособный продукт. А как его отдать, когда вы не знаете, что у вас по бюджету, времени и где вы в части исполнения - на каком этапе.
9️⃣Стенды. Тут нужно не ветки отпочковывать, а сделать полноценный тестовый стенд. Это оптимизирует процессы тестирования и интеграции и ускорит выявление и исправление критических ошибок.
1️⃣0️⃣Открытая коммуникация в команде и профилактика выгорания. Важно, чтобы все были в курсе текущих целей и задач, не дублировали чужую работу, не пропускали исполнение функциональности. Все мы знаем как напряжение и тем более конфликты стопорят разработку.
Расскажите, какие еще пути оптимизации вам пригодились на этапе разработки MVP
➡️Сегодня предлагаю обсудить проблему перерасхода ресурсов на проекте, и как его избежать.
1️⃣Цели. Начнём с основы - когда вы только начали разработку MVP, донесите всей команде основные цели.
2️⃣Приоритизация. Мои подписчики наверняка прекрасно знают, что это и как это работает. Сосредоточьтесь главным образом на том, ради чего которого и затевалось это MVP.
3️⃣Демо - как можно чаще. Вам нужно быть и с заказчиком (в первую очередь) и с пользователями — on the same page.
4️⃣Жесткие дедлайны - все мы - менеджеры, немного драконы😁 Установите жёсткие ограничения на время и другие ресурсы на MVP.
5️⃣Метрики. До старта согласуйте метрики успешности MVP с заказчиком. Это не даст разрастись бэклогу mvp, а ещё поможет сосредоточиться на достижении четких результатов.
6️⃣Минимум документации - не надо убивать время на документирование. Да, важно и нужно самое-критичное фиксировать. А в остальном от вас ждут результат mvp - продукт, а не бумажки. Их можно сделать в конце или параллельно. В процессе разработки MVP меняется - вы просто убьете время на документирование.
7️⃣Техдолг. Я всегда была и есть за качество. Но не стремитесь к идеальному коду на этапе MVP, находите баланс, чтобы быстрее получить продукт и получить пользовательскую обратную связь. Берем в работу то, что архиважно, что скажется на архитекттуре или приниципиально важных вещах в части разработки, качества и поддержки(!)
8️⃣Ганта - нельзя пилить MVP без роадмапа! У вас короткий срок и нужно отдать жизнеспособный продукт. А как его отдать, когда вы не знаете, что у вас по бюджету, времени и где вы в части исполнения - на каком этапе.
9️⃣Стенды. Тут нужно не ветки отпочковывать, а сделать полноценный тестовый стенд. Это оптимизирует процессы тестирования и интеграции и ускорит выявление и исправление критических ошибок.
1️⃣0️⃣Открытая коммуникация в команде и профилактика выгорания. Важно, чтобы все были в курсе текущих целей и задач, не дублировали чужую работу, не пропускали исполнение функциональности. Все мы знаем как напряжение и тем более конфликты стопорят разработку.
Расскажите, какие еще пути оптимизации вам пригодились на этапе разработки MVP
The next bit isn’t clear, but Durov reportedly claimed that his resignation, dated March 21st, was an April Fools’ prank. TechCrunch implies that it was a matter of principle, but it’s hard to be clear on the wheres, whos and whys. Similarly, on April 17th, the Moscow Times quoted Durov as saying that he quit the company after being pressured to reveal account details about Ukrainians protesting the then-president Viktor Yanukovych. "We as Ukrainians believe that the truth is on our side, whether it's truth that you're proclaiming about the war and everything else, why would you want to hide it?," he said. In addition, Telegram's architecture limits the ability to slow the spread of false information: the lack of a central public feed, and the fact that comments are easily disabled in channels, reduce the space for public pushback. But the Ukraine Crisis Media Center's Tsekhanovska points out that communications are often down in zones most affected by the war, making this sort of cross-referencing a luxury many cannot afford. At its heart, Telegram is little more than a messaging app like WhatsApp or Signal. But it also offers open channels that enable a single user, or a group of users, to communicate with large numbers in a method similar to a Twitter account. This has proven to be both a blessing and a curse for Telegram and its users, since these channels can be used for both good and ill. Right now, as Wired reports, the app is a key way for Ukrainians to receive updates from the government during the invasion.
from ar
