Разработчик пишет код, после чего показывает коллеге или тимлиду. Рецензент изучает код и указывает разработчику на мелкие ошибки или концептуальные промахи. На тест идёт уже более-менее рабочий код.

Очень хорошая практика, способствующая росту опыта разработчиков и сокращению времени на тесты.
 
 
Аналитик собирает, анализирует и формулирует требования, после чего показывает коллеге или руководителю. Рецензент изучает требования и указывает аналитику на мелкие косяки (например, недостаточно полное описание) или существенные проблемы, способные поломать логику работы комплекса.

Очень хорошая практика, способствующая росту опыта аналитиков и сокращению времени на переделку функционала, который работает правильно, но не так, как нужно клиенту.
 
 
Я не верю в пользу рецензий и ревью.

Проблема в том, что все положительные моменты перекрываются формированием у исполнителей особого мировоззрения «если я ошибся, рецензент заметит». Интересно, я все проверки предусмотрел? Да вроде все, но если что-нибудь упустил, рецензент укажет, а если не укажет — что поделаешь, он же опытней.

Нет.

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

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

Автор наблюдал ситуацию, когда разработчик в ранге чуть выше джуниора был направлен наставником на единоличную автоматизацию оперативного учёта небольшого, но очень интенсивно работающего предприятия, где цена дефекта астрономически высока. Рецензии? К чёрту, он справится. Джуниор допустил несколько ошибок, лично их исправил, обзавёлся несколькими седыми волосами от одновременных гневных звонков по двадцати восьми линиям во время аварийных остановок серверов и успешно закончил проект, попутно очень чётко осознав, что он лично отвечает за всё происходящее, проверять за ним некому, допускать ошибки, надеясь на рецензента, нельзя. Нужно ли говорить, что этот человек дорос до полноценного сениора и сейчас руководит разработкой масштабных нагруженных проектов?

Я считаю рецензии потерей времени.

Как бы ни был удобен evernote, всё равно чёркаю ручкою по бумаге и постоянно ищу удобные формы фиксации рабочих заметок.

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

Обнаружил намного более интересный метод, зовётся Scription Chronodex. Центром листа является шлоебень в виде ступенчатого циферблата, содержащего секторы рабочих часов, разбитые рисками на пятнадцатиминутные промежутки. Вот она:

При помощи данного циферблата можно отмечать сделанные активности, штрихуя части секторов и рисуя от них веточки наподобие ментальной карты, либо планировать активности, делая то же самое карандашом.

В центре — циферблат, на периферии — произвольные заметки. В нижней части листа — стандартный GTD лист следующих действий, инбокс и область отложенных дел.

Использовал около полутра лет, потом отказался — данный инструмент не учитывает специфику моей работы. Выглядело это примерно так:

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

Относительно заштрихованных кружочков:

1

Error happened.

Хотелось бы поделиться результатом сегодняшнего эксперимента — грибные спагетти с томатным соусом. Готовим без майонеза же.

1. Вермишель закидываем вариться по любимому рецепту. Я предпочитаю кидать в воду три щепоти соли, немного растительного масла и ставить на сильный огонь. Закипит — убираем пламя до минимума и кладём деревянную ложку поперёк кастрюли (чтобы вода не выкипала). В общей сложности они готовятся около пятнадцати минут. После этого три минуты держим под крышкой с выключенным газом, затем выкладываем на дуршлаг (холодной водой не остужать, это горячее блюдо!!!)
 
 
2. Параллельно с вермишелью готовим соус:

✔ Томатная паста — маленькая баночка.
✔ Чеснок — один зубец.
✔ Лук — две пластинки.
✔ Гвоздика — три гвоздя.
✔ Чёрный молотый перец — две щепоти.
✔ Горячая вода — грамм двести.
 
Дальше ВНЕЗАПНО я взял пакетик с «Горячей кружкой». Поясняю — кошерно использовать куриный бульон, но мне впадлу отваривать курицу ради стакана бульона. Херачим содержимое «Горячей кружки» и не паримся.

Чеснок мелко рубим, лук тоже. Засыпаем все компоненты в металлическую кастрюлю с толстыми стенками (я использовал большую металлическую кружку с крышкой). Заливаем кипятком из стакана и ставим на медленный огонь.

Вывариваем до густоты под крышкой. У меня вышло около пятнадцати минут.
 
 
3. Процеживаем содержимое соусной кастрюли через сито, выливаем на глубокую сковороду. Туда же выкладываем вермишель из дуршлага, добавляем заранее припасённые грибы (можно заменить кусочками курицы или бекона, пофиг).
 
 
4. Тушим под крышкой около пяти минут. Выключаем газ и остужаем пять-семь минут, чтобы это можно было есть не обжигаясь. Наверное, можно посыпать сыром, но я забыл купить сыр.

На вкус — остро и божественно. Так как соус изобрёл с нуля, использовал малые дозы, чтобы не переводить продукты.

Управление женским коллективом имеет свои особенности. Женщины работают не хуже мужчин (а некоторые занятия даются им значительно лучше), но они зачастую слишком эмоциональны. Замечание по рабочему вопросу может вывести сотрудницу из равновесия на продолжительный период. Они никогда не забывают мелких обид, зачастую формируют коалиции, бойкотируют неугодных, могут не выполнить указание руководителя, не объясняя причин. Кроме того, очень часто семья для сотрудницы приоритетнее работы. Не учитывать этот факт — потерять лояльность, а в перспективе получить ненужную текучку кадров.
 
Есть несколько правил, соблюдение которых позволяет держать женский коллектив в стабильном состоянии.
 

Не реагировать на жалобы сразу.

Если сотрудница пришла во взвинченном состоянии и жалуется на кого-либо, следует её выслушать, задать уточняющие вопросы, сделать записи и… ничего не делать. В большей части случаев, когда утихнут эмоции, уйдёт и проблема. В меньшей (когда проблема не выдумана), сотрудница сама предложит вариант решения.
 

Стандартизировать процессы.

Мужской коллектив зачастую предпочитает «атмосферу стартапа», для женского нужны чёткие стандарты, а также тщательный контроль за их соблюдением, это даёт чувство определённости и защищённости.
 

Убеждать по одной.

Для того, чтобы эффективно запустить в женском коллективе использование нового процесса или технологии, нужно по очереди лично убедить в этом двух сотрудниц, в этом случае сопротивление будет значительно ниже. Ни в коем случае нельзя обрабатывать групповые жалобы, споря со всем коллективом, только по одной.
 

Осознавать, что личные проблемы для сотрудницы важнее рабочих.

Если сотрудница просит уйти пораньше, чтобы забрать ребёнка из детского сада или внеочередной отпуск, чтобы познакомить жениха с родителями, живущими в другой области, нужно идти навстречу. Не пойдёте — потеряете специалиста. Отнесётесь по-человечески — получите лояльность.
 
 
Если вы всё делаете правильно, сотрудницы будут проявлять инициативу, а внедрение новшеств и корректировок процессов будет проходить гладко и до конца.

Осажденный изголодавшийся Париж (осада Парижа пруссаками началась 16 сентября 1870 года. В январе 1871 года, когда происходит действие новеллы, пруссаки начали артиллерийский обстрел Парижа) был при последнем издыхании. На крышах почти не осталось воробьев, в сточных канавах — отбросов. Люди ели все подряд, без разбора.

Слушать

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

Больничные.

Заболевшие сотрудники заражают коллег. Совершенно необходимо отправлять заболевших сотрудников домой. Если человек может работать, пусть работает удалённо,, если не может — пусть отлежится два-три дня. Не надо в этом случае требовать больничный. Зачастую для того, чтобы отлежаться при простой простуде, достаточно двух-трёх дней. Если заставить брать больничный, сотрудник пойдёт в больницу, с большой вероятностью что-нибудь там подхватит и выйдет из строя на несколько недель.

Почему бы не купить витамины? Они не так дорого стоят. Купить и поставить баночки в кабинетах. Ещё можно устроить добровольную вакцинацию, это тоже не очень дорого (по сравнению с потерями от постоянного отсутствия сотрудников). Да, на это деньги нужны, но прививки работают.
 

Отгулы.

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

Можно разрешить сотруднику отработать отгул в субботу. Доводы против — не во всех случаях это целесообразно. Например, менеджер по продажам канцелярки вряд ли что-нибудь продаст в субботу, когда большинство офисов закрыты. Но, к примеру, разработчик вполне может что-нибудь порефакторить в спокойной обстановке и проч.
 

Отлучки в рабочее время.

Допустим, сотруднику нужно съездить куда-нибудь во время рабочего дня. Почему бы не разрешить ему воспользоваться служебным автомобилем?
 
 
Если проявлять заботу о сотрудниках, им будет значительно меньше хотеться халтурить и стремиться свалить подальше из офиса при первой возможности.

Беда множества стартапов в том, что ещё на этапе постановки целей автор ориентируется «на сейчас» (а в худшем случае — «на вчера»). Выпускаемый продукт, естественно, оказывается заранее устаревшим.

Мне доводилось работать в продуктовой компании под руководством очень интересного директора по разработке. Наши диалоги были такими:

— Владимир, разработай, пожалуйста, такой-то элемент для приложения.
— Вот, пожалуйста, четыре варианта.
— А какие продукты конкурентов ты проанализировал, прежде, чем это придумать? Может быть, стоит посмотреть, как это реализовано у них? Понимаешь, если твиттером пользуется стотыщмиллиардов людей, может быть, они привыкли к твиттерной версии? Или ещё какой-нибудь? Иди-ка, проведи исследование конкурентов.

Следствие подобного подхода — «завтрашние» возможности продукта оказываются «вчерашними» возможностями конкурентов. Плюсы — можно сделать коммерчески более-менее успешный продукт-середняк, который будет приносить прибыль. Минусы — прорывной, революционный продукт так не сделать.

Можете себе представить Джобса, исповедующего оглядку на конкурентов? Да он никогда бы не решился рискнуть выпустить телефон без кнопок. Это же рискованно, все привыкли к смартфонам с клавишами.

«В-третьих, телефон без кнопок — говно, потому что за рулем уже номер на ощупь не наберешь. И эсэмэску не отправишь нормально. Остается надеяться, что производители типа «Гриффина» или «Белкина» уже разрабатывают подключаемую клавиатуру.

В целом ничего особенно нового «Эппл» не представил, кроме скорости и хорошего интерфейса. Функции «Айфона» (включая тачскрин) многократно перекрываются предложениями других производителей (которым не хватает только скорости и нормального интерфейса).»

Первое впечатление Лебедева об айфоне.

И что? Пользуется за милую душу и никакой другой смартфон более не признаёт. Потому что Джобс смотрел не на конкурентов, а на тренды.

Анализ трендов — единственный способ создать революционный продукт. Анализ конкурентов полезен для того, чтобы не повторять их ошибок.

Надпись на «Post hoc non propter hoc» на картинке переводится с латыни как: «После не означает вследствие». Общеизвестно, что причины провалов нужно тщательно исследовать, как бы ни был провал неприятен, а причины его глупы. А вот причины успехов — нет.

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

Иногда успех приходит не благодаря, а вопреки или даже из-за цепочки случайных событий. Рассмотрим несколько утрированный пример.

Менеджер предположил, что разводить уток в данной местности целесообразнее, чем кур из-за более высокого спроса. Ферма уток дала фантастическую прибыль. На самом же деле, причиной успеха стал прорыв дамбы, наводнение и массовая гибель кур в данном регионе, повлекшая рост спроса на утиное мясо. Не будь наводнения, местное население продолжило бы питаться курятиной и проект с утками бы провалился.

Анализировать причины успехов настолько же важно, как и разбирать неудачи.

У прочитавших пост о группе управлении разработкой закономерно возникнет вопрос — почему я не упомянул о команде тестировщиков и QA лидере?

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

Тестировщик является важнейшей фигурой процесса разработки. Он, и только он может принять решение о готовности доработки к вливанию. Только глава QA может дать добро на релиз данного билда, когда будет уверен в том, что все критичные дефекты исправлены.

Тестировщика обязательно нужно подключать к обсуждению на этапе написания требований. Дело в том, что эта категория специалистов обладает специфическим «разрушительным» мышлением и находит ошибки в требованиях намного эффективнее коллеги-аналитика с «созидательным» мышлением, выступающего в роли рецензента.

Возможны три подхода к организации группы тестирования:

1. Выделенный департамент тестирования, обслуживающий все продукты.
2. Тестировщики как части универсальных кросспродуктовых команд.
3. Тестировщики как части микрокоманд.

Выделенный департамент тестирования.

Все тестировщики выделены в обособленное подразделение, которое проводит тестирование всех программных продуктов, выпускаемых компанией.

Данный подход оправдан для организации тестирования в компании, выпускающей обширную продуктовую линейку. Тестировщиков в этом контексте «натаскивают» на все продукты линейки, что позволяет балансировать ресурсы в зависимости от нагрузки.

Схема имеет существенный недостаток — как бы гладко ни был построен процесс планирования работ, при старте доработки QA лидер не может определённо сказать, кто именно будет тестировать. Тестировщик будет поставлен перед фактом по готовности доработки и не будет иметь достаточно времени для полноценного вникания в требования. Знакомить всю тестировочную группу с требованиями ко всем доработкам всех продуктов нецелесообразно — сотрудник будет внимательно слушать только если есть гарантия, что проверять данную доработку придётся именно ему.

Тестировщики как части универсальных кросспродуктовых команд.

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

Тестировщики как части микрокоманд.

Почти идеальный подход. При старте доработки формируется микрокоманда из аналитика, нескольких разработчиков и тестировщика. Микрокоманда ведёт производство на всех этапах, от сбора требований, до финальной сдачи заказчику (вливания в релизный билд в случае продуктовой разработки). Тестировщик микрокоманды находится в курсе требований с самого начала и готовит план тестирования с момента передачи требований разработчику, а не по готовности доработки, что позволяет тестировать комфортно, оперативно и эффективно.

Для того, чтобы руководить разработкой продукта, нужно уверенно держать в руках три «руля»:

1. Административное руководство.
2. Управление изменениями.
3. Техническое и архитектурное управление.

 
 
Рассмотрим все три «руля» более подробно.

Административное руководство.

Сюда входят четыре из пяти менеджерских компетенций, а именно планирование, организация, кадры и контроль.

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

Организация — процессы, напрямую не связанные с производством, но влияющие на него. Инфраструктура (рабочие места, обеды, кофе и проч.) и обеспечение коммуникаций.

Кадры — рекрутинг сотрудников, мотивация.

Контроль — умение держаться полностью в курсе событий. Делать это нужно очень деликатно и малоинвазивно, сотрудники не любят плотный контроль. Помимо информации о том, какая задача у какого исполнителя в работе, необходим контроль всех ключевых показателей для отчётности финансовой службе.

Данного перечня работ вполне достаточно для полной загрузки менеджера продукта. При попытке навесить на него второй и третий «рули» возникнет сбивание фокуса и падение производительности всей команды.
 
 

Управление изменениями.

Разработчики пишут код по техническим заданиям/требованям, которые должны быть собраны, проанализированы и формально описаны. Кроме того, необходимо на протяжение всей работы над продуктом не упускать из внимания vision — общую концепцию, идею. Сюда входят следующие работы:

Vision — умение не поддаваться желанию навесить на продукт как можно больше функций, забыв о его основном назначении.

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

Управление пользовательской документацией. Технические задания, равно как и требования к продукту пользователям показывать нет нужды, для них необходима документация в привычном формате. Исключение составляют продукты, не требующие документации для использования, обычно это небольшие приложения: мессенджеры, заказ еды или такси, простейшие игры и проч.

Данного перечня работ достаточно для полной загрузки главного аналитика продукта. Именно этот человек должен в деталях знать, как работает продукт на уровне возможностей. Что можно, чего нельзя. Менеджер продукта формирует направление и сроки, главный аналитик организует проработку требований и обеспечение разработчиков техническими заданиями.
 
 

Техническое и архитектурное управление.

Сюда входит группа работ по обеспечению производства. А именно:

Архитектурное управление — обеспечение технической целостности и непротиворечивости работы модулей системы, структуры базы данных и проч.

Методологическое управление. Организация рецензирования кода, парного кодирования и прочих практик экстремального программирования, а также любых других практик, способных быть полезными.

Обеспечение технической инфраструктуры — выбор среды разработки, версионного хранилища, организация сборок билдов, методов передачи на тестирование.

Обучение. Организация обучения джуниоров, повышение квалификации мидлов, поддержание матрицы компетенций.

Управление технической документацией. Организация написания технических спецификаций. Особенно актуально для работы над продуктом, являющимся частью комплекса ПО. Без технических спецификаций (это третий вид документации) реализация взаимодействия продуктов будет затруднена.

Консультации аналитиков, выработка вариантов реализации.

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

Данного перечня работ достаточно для полной загрузки главного разработчика продукта. Этот человек полностью отвечает за группу разработчиков и больше ни за что.
 
 
Таким образом, мы видим три роли, способные, грамотно взаимодействуя, обеспечить непрерывный и стабильный процесс разработки продукта. За кадром осталось тестирование, но его мне хотелось бы рассмотреть в отдельной статье.

Человек, полностью ответственный за продукт — менеджер продукта. Безусловно, в принятии решений должны участвовать все три менеджера, но старшим руководителем, обладающим право вето и последним словом является именно менеджер продукта. Главный разработчик и главный аналитик стоят на одном уровне и руководят группой разработчиков и группой аналитиков соответственно.