Zerocracy - отличная платформа для управления проектом по разработке программного обеспечения… если вы понимаете, как работает мир диких животных, также известный как фрилансеры-микрозадачники, работающие за результат. Если вы будете обращаться к ним так, как вы привыкли обращаться к традиционным полноценным программистам, вы проиграете. Вы потеряете свои деньги, свое время и будете обвинять Zerocracy. Я не хочу, чтобы это случилось, поэтому этот блог-пост с кратким списком важных принципов/подсказок.
Сначала Прототип. Не позволяйте архитектору приглашать программистов в проект, пока прототип не будет готов, конвейер сборки настроен, и продукт развернут в продакшн, как предлагает наш Цикл Жизни. Вы должны визуально подтвердить, что прототип доказывает, что ключевая техническая цель проекта достижима. Только после этого вы начинаете добавлять программистов в команду.
Строгий Конвейер. Не утверждайте прототип, если его конвейер сборки не включает 1) модульное тестирование, 2) статический анализ и 3) контроль покрытия тестами, как предлагает этот блог-пост. Там может быть больше элементов, но эти три обязательны.
Только для Чтения. Никогда не позволяйте никому, включая себя, сторонних экспертов, ваших полноценных сотрудников или аудиторов, иметь доступ на запись к ветке master, как объясняется в этом блог-посте. Если архитектор настаивает на этом, сообщите нам, мы его/ее распнем.
Не Торгуйтесь с Тарифами. Не платите меньше, чем просят фрилансеры. Хорошо, иногда вы можете поступить так, но как правило, я бы посоветовал соглашаться на то, что они просят. Наша система управления очень строгая, требовательная и стрессовая. Вы можете потерять хороших людей, если они будут недовольны финансово. Так что не будьте жадными, вы только проиграете и останетесь с слабыми программистами.
Не Чатите. Скорее всего, вы привыкли общаться с программистами в чатах, таких как Slack или Telegram. Вы сделаете себе плохую услугу, если будете продолжать делать это с архитектором Zerocracy или, не дай бог, программистами. GitHub должен быть вашим единственным инструментом общения, как предлагается в этом блог-посте. Вам все еще удобнее звонить по телефону? Вините себя, когда проект развалится.
Не Доверяйте Им. Каждую неделю вы обязательно должны приглашать внешнего аудитора в ваш репозиторий и просить его проверить, что не так и что можно улучшить, как предложено здесь и здесь. Требуйте, чтобы они ответили хотя бы на эти вопросы и предоставили свой отзыв в виде GitHub тикетов.
Общайтесь с Сообществом. Когда вы готовы начать проект, отправьте RfP. Сразу после этого присоединитесь к нашему Telegram чату. Оставайтесь там и задавайте все вопросы, которые у вас есть о вашем проекте, о продвижении, ошибках, которые, по вашему мнению, совершает ваш архитектор или ваша команда. Не молчите, делитесь своими опасениями! Мы поможем. Если вы попытаетесь решить их сами, вините себя, когда проект провалится.
Сначала Прочтите. Вы обязательно должны прочитать/посмотреть эти статьи и видео:
“Как избежать катастрофы при аутсорсинге программного обеспечения”
Meetings Are Legalized Robbery - Встречи - это легализованное грабеж.
Сфокусируйте их. Не позволяйте им работать без контроля за фокусом. Убедитесь, что ваш архитектор знает, какие части объема работ являются самыми важными, и сосредоточьте команду на работе с ними в первую очередь. В этом видео объясняется, как можно использовать фактор усиления, вехи и ручные назначения для этого.
Наймите QA. У нас в Zerocracy есть специальная роль, известная как Quality Assurance (QA). Она была изобретена для предотвращения нарушения наших правил работы. Крайне рекомендуется нанять QA при начале проекта. Возможно, вы не видите, почему это важно, но поверьте нам, без QA ваш проект находится под огромным риском потери дисциплины и денег.
Продолжайте набирать сотрудников. Даже когда вы думаете, что ваша команда полна и у вас достаточно программистов, не расслабляйтесь. Постоянно нанимайте новых людей. Опубликуйте свой проект на нашей доске и объявите его в нашем Telegram-чате. Чем больше команда, тем больше шансов на успех вашего проекта.
Выпускайте ежедневно. Сразу после того, как прототип готов, убедитесь, что ваш продукт выпускается как минимум каждый день. Убедитесь, что вы можете выпустить его самостоятельно, без помощи архитектора. Настаивайте на том, чтобы архитектор настраивал процесс доставки и передавал его в ваше управление.
Translated by ChatGPT gpt-3.5-turbo/42 on 2024-05-27 at 01:20
