#процессы

Что отличает хорошие команды разработки от плохих?

Единого правильного ответа нет — команда это инструмент решения задач бизнеса и каждой задаче свой инструмент. А еще это вопрос ценностей.

Для меня в разработке важны два принципа, из которых можно вывести все остальное:

1. Заинтересованность в конечном результате. Способность и настроенность не «работу делать», а «получать результат, двигаться к результату». Не путать с горящими глазами! Восторженность не обязательна, но безразличие опасно.

2. Предсказуемость. Раньше я называл это «способность выполнять обещания», и это простой критерий, но как и любую формальную метрику его можно обмануть — например, не давать обещаний. И очень уж фонит трудным детством в казанских кварталах: «пацан слово дал» и вот это все. Предсказуемость включает в себя выполнение данных обещаний, но еще и прозрачность, проактивное обсуждение возникающих трудностей (а они точно будут), формирование реалистичных ожиданий.

А что для вас главное в разработке? Интересно, будут ли отличаться ответы разработчиков и продактов, бизнеса? Пишите пожалуйста в чатик @ctodailychat или в личку @samatg

Basecamp написали подробную книгу, как они строят свою работу.

Эти ребята умудрились вырастить продуктовую компанию из 2 человек в 50 и не потерять при этом жизнь, скорость и кайф в том, чем они занимаются.

Всё бесплатно, онлайн, с примерами из реальной жизни.

💘 https://basecamp.com/shapeup

Фёдор Борщев отвечает на вчерашний пост про Agile:

Красноречивый наброс на скрам, мол, Agile > Scrum = 💩 и у всех прорывает.

Если вы ничего не поняли — это нормально. Фраза — практически тест на то, занимались ли бизнес-программированием в последние 5 (10?) лет.

Agile — идея (учение) о том, как правильно разрабатывать программы. Вот простой для понимания первоисточник, рекомендую: 12 заповедей (принципов) Agile (русский перевод). Оцените полет мысли, это практически госпел (понимаю, почему его так любит Герман Греф).

Я капитально упорот на идее servant leadership и работал исключительно в стартапах. Даже я чувствую иррациональный страх перед идеями Agile. Уровень страха нормальных менеджеров можно сравнить со страхом фарисеев перед идеями Христа, я думаю. Поэтому авторами Agile Manifesto был придуман SCRUM.

SCRUM — четко описанные процессы, где отдельный человек и даже продукт уже не так важны. Можно стать сертифицированным коучем SCRUM, есть курсы SCRUM, можно повесить себе шильдик «успешно внедрили и следуем СКРАМ» и т.д.

Разница между Agile и SCRUM — примерно как между учением Христа и табачным бизнесом РПЦ. Поэтому в классных компаниях ценят результат и людей, этот результат достигающих, а в стремных — «процессы». Аминь.

@pmdaily, что скажешь?

Провели сегодня мега-совещание про работу разработки с дизайнерами. Покажу вам, какое письмо я разослал по окончании встречи.

Размер и сложность продукта растет, старые процессы уже не выдерживают. Копится недовольство с обоих сторон и вообще, нужно было поговорить.

Резюме совещания:

про макеты:
- постепенно создаем один мастер-макет, в котором отрисованы все форматы медузы и в который добавляются новые, перестаем использовать отдельные маленькие макеты как источник правды;
- с помощью этого мастер-макета постепенно уменьшаем количество разных элементов, выносим все общие элементы в стайлбук;
- если в новых форматах есть неочевидные моменты (заголовок изменился на 1 пункт, так просто не заметишь) — указываем эти комментарии прямо рядом элементом, на полях артборда;
- этот мастер-макет храним в версионированном хранилище с возможностью просмотра диффов и автоматическими уведомлениями о правках (скорее всего github + скетч-плагин, но если найдем хороший SaaS — то вполне может и на него сядем);

про совместную работу:
- задача разработчиков — в процессе разработки (чем раньше тем лучше, идеально во время приемки) найти недорисованные/недодуманные моменты и сказать о них дизайнеру. Например, если не учтена ситуация, когда одно из полей пустое — не очевидно, какие отступы делать в этом случае. Дизайнер дорисует эти кейсы и/или добавит в макет комментарий, объясняющий логику;
- если что-то очень сложно сделать на платформе (белая тень, хитрый блюр, etc.) — обсуждаем это с дизайнером. Что нужно в разговоре? 1) объясняем что именно сложно сделать и почему 2) предлагаем решение, как вы думаете можно упростить/сделать по другому 3) приходим вместе к компромиссу. Никто не требует делать безумные хаки, которые дорого поддерживать и которые ломаются с апдейтом чего-нибудь. Все мы хотим классный продукт и дизайнер мог просто не знать/забыть о платформо-специфичной вещи;
- вывод: Не стоит допридумывать то, что не описано/не нарисовано. Нужно договариваться. Молча делать отлично от макета запрещено;

В заключение: разработчики — полноценные члены продуктовой команды. Думайте о продуктовых фичах, задавайте вопросы, предлагайте идеи. Не все они будут реализованы, часть задвинем в дальний ящик и никогда до них не доберемся. Это нормальный рабочий процесс — то же происходит с идеями редакции, дизайнеров и даже Ильи. Мы (разработчики) обладаем уникальным знанием того, как это всё будет реализовано в конечном счете. Без нашего участия сделать классный продукт невозможно.

Теперь о том, где, как и с кем это всё обсуждать.

1. О каких-то мелких непониманиях по дизайну стоит писать в личку Насте, Вите и Насте; можно созвониться-пошарить экран и тд, если текст не решает;
2. О крупным вещах, которые хочется обсудить с командой и с дизайнерами — пишите прямо в #dev или в проектный канал типа #dev-prodano
3. Если это тема в проектной работе, которая требует осмысления и обсуждения — круто завести для неё карточку в трелло-доске проекта и заменшенить в комментарии всех причастных. В трелло обсуждения не теряются и можно посмотреть толком историю переписки по конкретному вопросу.

Воспользуюсь случаем и напомню, что текущие проекты, предстоящие задачи и icebox (то, что хочется сделать, но хз когда) можно посмотреть в доске «проекты разработки» — он открыт для всех, изучайте и дополняйте, пожалуйста.

-----

А как вы строите работу дизайнеров с программистами? Делитесь в @ctodailychat, интересно послушать ваши истории.