Эффективность методов передачи информации (по убыванию):

1. Личный разговор у маркерной доски.
2. Видеозвонок.
3. Голосовой звонок.
4. Переписка в текстовом чате.
5. Email переписка.
6. Чтение документации.

 
 
Регулярно слышу такие фразы от сотрудников:

— Он спросил, а я ему ответил: «Читай документацию, там всё написано». Понанимали по объявлениям, никто не может документ прочитать.

 
Или такие:

— Разработчик Вася делает не то, что нужно. Я передал ему всю необходимую информацию, а он реализовал совершенно не то.

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

Чтение документации:

Так. Тут написано, что нужно импортировать торговые точки из Excel файла. Понятно, такое уже приходилось делать, ничего особо сложного. Меня интересует описание каждого поля. Так, активность. В документе сказано, что в поле активности может стоять нуль, единица или пустое значение. Видимо, единица означает активную точку, нуль — пассивную. Интересно, а что означает пустое значение. Null — это не нуль. Но уж точно не единица. Может быть, спросить аналитика? Не хочу, он опять скажет: «Читай документацию, там всё написано». Буду интерпретировать как нуль.

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

Личный разговор:

— Привет. Я принёс документ с описанием импорта торговых точек из Excel файла. Давай вместе его посмотрим.
— Да, смотрю. А скажи, пожалуйста, вот ты написал, что в поле активности может быть пустое значение. Как его интерпретировать?
— Опаньки. Что-то я об этом не подумал. При импорте новой точки пустое поле означает активную торговую точку (по бизнесу нет смысла создавать точки неактивными), при апдейте существующей торговой точки пустое значение интерпретируется как «не трогать существующую активность». Спасибо за замечание, я немедленно внесу правки.

Результат — ошибка отловлена на ранней стадии, разработчик сделал именно то, что нужно, доработка была успешно сдана.
 
 
 
«Шумы» — не самая большая беда. Часто злоупотребление виртуальной перепиской приводит к абсолютно ненужным конфликтам. Текст воспринимается совершенно не так, как речь. Безусловно, если сотрудник работает удалённо, без виртуального общения не обойтись, но в этом случае рекомендуется как можно чаще использовать видеосвязь и голосовые звонки. Если же сотрудники сидят в соседних кабинетах, необходимо убеждать их не лениться ходить друг к другу и обсуждать вопросы лично.
 
 
Рассказ коллеги:

Знаешь, меня всё время бесил один сотрудник. Прочитаю очередное его письмо и аж закипаю, ну как можно писать такой идиотизм!!? Наконец, не выдержал и пошёл к нему на второй этаж. Подхожу, значит, спрашиваю:
— Вот почему ты это написал? Зачем? Что ты имел в виду?
— Вот это, вот это, вот это, вот так и вот так.
— Стоп… Так всё же верно ты говоришь. Так почему же ты пишешь такую ересь?
— Всё я правильно пишу. Что имел в виду, то и написал.

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

Вводная:

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

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

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

Вопрос:

Как определить, какой запрос нужно взять в работу? Кажется, что решение лежит на поверхности — запрос с высшим приоритетом. Однако есть один подводный камень — высшее руководство назначает приоритеты, исходя из нужд клиента и совершенно не думает о наличии/отсутствии у разработки ресурсов, чтобы тот или иной запрос выполнить.

Первый вариант решения:

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

Результат: Месячный лаг, негатив от всех клиентов, не заработали ничего.

Второй вариант решения:

Смотрим на очередь, видим запрос на продукт № 1. Проверяем наличие ресурсов в команде продукта № 1 и осознаём, что их нет. В то же время, в продукте № 2 свободные разработчики имеются, мало того, ощущается недостаток задач. Берём запрос на продукт № 2, проводим через аналитиков, сразу же отдаём в работу, получаем деньги.

Результат: Заказчик высокоприоритетного запроса недоволен, высшее руководство тоже — запрос с высшим приоритетом не пошёл в работу. Сделали запрос с более низким приоритетом, заработали деньги.

Вывод:

В ситуации, когда приоритетами управляет высшее руководство, а аналитики работают на все продукты сразу, правильный алгоритм определения запроса для взятия в работу таков:

1. Выяснить наличие ресурсов во всех продуктах.
2. Взять в работу самый приоритетный запрос на этот продукт.

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

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

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

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

Нет.

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

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

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

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

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

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

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

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

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

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

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

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

1

Error happened.

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

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

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

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

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

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