Классическое блюдо русской кухни.
 
 
Минимальный набор продуктов:
   Любое мясо
   Сливки
   Томатный сок
   Чеснок
   Крахмал
   Вода
   Сметана
   Соль и перец.
 
 
Было бы неплохо иметь:
   Зелень
   Немного грецких орехов
   Лук
 
 
Погнали. Первой итерацией готовим компоненты.

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

В стакан льём томатный сок. Кидаем туда измельчённый чеснок, размешиваем. Если есть грецкие орехи и зелень, тоже измельчаем и фигачим туда же. Ставим в сторону.

В стакане холодной воды растворяем чайную ложку крахмала. Ставим в сторону.

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

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

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

В ковшик со сливочным соусом добавляем сметану.

Примерно десять минут мясо будет бурлить в томатном соке параллельно со сливочным соусом.

Как добурлит — выливаем сливочный соус на сковороду с мясом и доводим под крышкой ещё минут десять, подаём горячим.

Традиционный гарнир для этого блюда — жаренная картошка, но ограничился зелёным горошком.

Есть компании, старательно «работающие с негативом» и старательно оправдывающиеся. Есть компании, которые просто обеспечивают качественный сервис.

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

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

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

Жёлтые объявили об улучшении тарифа. Уже точно не помню цифры, но речь шла о значительном повышении скорости за относительно небольшое увеличение абонентской платы. Сейчас могу соврать, но порядок такой — было 350 рублей за 10 мегабит, предложили 400 рублей, скажем, за 30. Или 50, не суть.

К сожалению, на деле озвученная скорость не достигалась. Ни при скачивании чего-либо, ни на тестах. Иногда 15 мегабит, иногда 9, иногда 20, но очень далеко от заявленной.

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

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

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

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

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

А дальше случилось нечто. Оказывается, заявленную скорость в 30 мегабит вполне можно обеспечить:

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

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

Задача сервиса не в сваливании вины на пользователя, а в своевременном решении проблем.

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

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. Тушим под крышкой около пяти минут. Выключаем газ и остужаем пять-семь минут, чтобы это можно было есть не обжигаясь. Наверное, можно посыпать сыром, но я забыл купить сыр.

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

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

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

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

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

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

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

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

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

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

Кейс с нужностью ограничений хорошо просматривается на примере организации каталогов товаров.
 
 
Хороший пример: Каталог магазина одежды 6pm.com Рассмотрим фильтр в разделе одежды для мужчин:

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

Данный подход к фильтрации преследует ещё одну скрытую цель. Сведение к нулю вероятности получения пользователем пустой выборки. Ситуация, когда пользователь вводит группу параметров, жмёт «Найти» или «Отфильтровать», а на выходе получает пустую выборку совершенно недопустима — две-три пустые выборки и он уходит в другой магазин. При помощи данного фильтра получить пустую выборку невозможно — перечень параметров также динамически меняется в зависимости от уже выбранных пунктов. Супер-пупер. Делали долго, дорого, расчудесно.
 
 
Чуть худший пример: Каталог магазина info39.ru, раздел планшетных компьютеров:

На динамическую выборку у создателей денег не хватило, но кое-что в плане минимизации пустых выборок сделано. Обратите внимание, я хочу найти все планшеты стоимостью от 20773 до 29773 рублей марки Asus. Таких планшетов в магазине нет. Есть планшеты указанного ценового диапазона, но асусовских среди них нет. Фильтр честно предупреждает — найдено ноль элементов. Тем не менее, нажать на кнопку «Применить» можно. В результате будет пустая выборка. Ну, не совсем пустая, а с заглушкой:

 
 
Плохой пример: Каталог магазина copicomp.ru, раздел беспроводного оборудования:

В этом фильтре плохо всё. На самом деле, в этом разделе нет товаров в выбранном диапазоне, но пользователь может об этом узнать только после нажатия на кнопку «выбрать»:

Надпись «В этой категории нет товаров». Ничего подобного, они есть, нет лишь товаров данного ценового диапазона. «Костыльным» решением было бы предложить пользователю наиболее близкие по цене товары, правильным — не дать получить пустую выборку.  Отсутствие динамической фильтрации также не делает чести данному каталогу.

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

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

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