#процессы

Краткие тезисы из статьи «как построена работа в Basecamp»:

- рабочие циклы по 6 недель. Внутри цикла могут быть до двух больших проектов продолжительностью на все 6 недель и пачка из 4-8 мелких, длящихся от дня до 2 недель каждый. Пример документа, описывающего цикл для команды;
- между циклами есть 1-2 недельное «свободное время», когда они чинят баги, занимаются side project и думают над следующим циклом;
- вся пачка мелких проектов делается одной командой, если в цикле два больших проекта — их делают две отдельные команды;
- самое необычное: команда это 1 дизайнер и один или два программиста; менеджером команды является дизайнер, но вся работа происходит сообща;
- чтобы пропитчить идею, её нужно оформить в связный текст с формулировкой проблемы и решения. Почему не голосом? 1) питчера не могу прервать и загнобить пока он не рассказал идею целиком 2) при написании текста питчер хорошенько над ней думает 3) асинхронное взаимодействие, они не особо любят слеки и личные встречи для работы 4) все комментарии к питчу собираются внизу как единый источник истины. Пример питча;
- координация и трекинг задач происходят в бейзкемпе, внутри всё стандартно;
- в цикле участвуют 2 QA-специалиста, они кочуют между проектами;

Уровень взаимного уважения и свободы в этой системе очень высокий, завораживает.

Я пока не ответили себе на вопрос, что в этой системе делают с задачами, в которых нужен бэкенд и мобильная разработка на двух платформах одновременно. Повышать число человек в команде нельзя — но как разбить задачу на проекты, если она по смыслу — одно целое? Пишите свои мысли в чатик @ctodailychat или личку @samatg.

Некоторые программисты недавно начали говорить, что у Apple «проблемы с софтом». Мол, во времена Джобса такого не было и вообще, раньше софт был надежнее.

Вот ответ от Стивена Сифонски. Это один из ключевых чуваков в MS: пришел в 1989, уволился в 2012 в должности руководителя разработки Windows https://medium.learningbyshipping.com/apples-software-problem-and-fixing-it-via-twitter-c941a905ba20

Вкратце: последние 15 лет Apple поставляет софт и железо со скоростью и качеством, не виданными в индустрии. При их объемах баг, затрагивающий 0.01% пользователей – это целый стадион недовольных. Кажется, что у Apple есть проблемы роста и это нормальный этап, который решается реорганизацией процессов; ничего драматичного.

Мы в Медузе уверенно программируем (и управляем разработкой), когда есть четкая постановка задачи — понимание, описание, макеты, тестовые данные и прочее.

Создаешь трелло доску со столбцами «описание», «разработка», «тестирование», «готово». Заводишь в неё все задачи. Даёшь внутри ссылки на .sketch-файлы. Созваниваешься перед началом проекта, обсуждаешь его голосом. Дальше постоянно контролируешь результат. Главное не забыть, что хотел получить в конечном счете.

Меня беспокоит этап, когда разработка формально ещё не началась. Собрать требования, разобраться в документации, разбить проблему на меньшие части, понять, что мы можем себе позволить, а что нет — всё это большая работа. В ней участвует не только разработка, но и дизайнеры и редакция. Сейчас эта работа делается ad-hoc, без «единого источника правды». Из-за этого возникает несколько связанных между собой проблем: 1. сложно оценить объем работы (сколько было/сколько сделано/сколько осталось) 2. сложно её делегировать (делать вместе) и делиться результатом 3. задачи теряются и забываются.

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

Попробуем сделать это с несколькими следующими проектами. Расскажу потом, что получилось.

Спасибо большое Боре Горячеву, что заметил проблему и указал на решение.