Products | People | Process

2020-11-16 09:04:04 Попалось интересное про слово test. Какое же ИТ без тестов...

Итак, testa в латыни это «скорлупа». Так римляне называли раковины и кусочки обожженной глины.

Отсюда черепаха это testudo. А внешний скелет морского ежа это и сейчас test.

В старофранцузском слово осело в значении «горшочек» (testum в латыни). Средневековые французские металлурги в таком горшочке делали пробу металла. Английские металлурги позаимствовали горшочек и с ним слово test как «проба» или «испытание».

отсюда Открыть/Комментировать

2020-10-16 11:56:36 ​​Очередное captain speaking…
Про NPS. Все, наверное, знают про такую характеристику продукта - Net Promoter Score. Задаем вопрос “Насколько вероятно, что вы нас рекомендуете своим знакомым?”. Затем из доли людей с высокими оценками (рекомендатели) вычитаем долю людей с низкими оценками (очернители). Это получается такая условная мера лояльности и любви.

Знаете с какого NPS мы начали, когда первый раз померили? -28% Когда я об этом упоминаю, некоторые пытаются меня убедить, что отрицательный NPS по формуле невозможен. А вот возможен (wiki в помощь)!

Главной претензией к NPS является то, что он не очень actionable. Делать нечего, берем телефон в руки и давай обзванивать респондентов. Раскидали контакты между американцами и теми русскими, кто не совсем отстойно говорит (я пролез!) и в бой. “Приветствую уважаемый! Вы нас тут в опросе запомоили, как насчет выбрать часик пообщаться?”. Ну и дальше уже распрашивали, что пошло не так. Простое правило для такого разговора - не убеждать, не обещать, не оправдывать. Это все только мешает. Надо просто слушать и спрашивать. На основе собранного всеми путями что-то меняли. За два года вышли в ноль. Год болтались у ноля. Потом рванули в плюс. Сейчас пересекли +67.

Потом стали умнее, встроили форму в продукт и добавили поля “что нравится?” и “что не нравится?”. Можно строить веселые квадранты - например, что нравится тем, кто нас не любит. Обрабатывать все равно руками. Раньше делал сам по 800 штук за раз. Отзывы веселые бывают - например “ненавижу вас, сволочи, а куда деваться. +9”

Вообще NPS можно не только к продукту проводить, но и к сотрудникам (у нас делают). На этом мы увидели классическую штуку - что в разных регионах численная оценка ставится разная. Где американец ставит 9, там русский ставит 5-6. Поэтому в продукте мы добавили кодирование смысла оценок цветом и смайликами.

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

Но вообще NPS это уже вчерашний день. В прошлом году прочел другую методику, которая мне больше нравится - это Fit For Purpose (F4P). Одноименная книга есть на Амазоне. Вкратце - даем возможность респонденту указать 3-5 важных ему критериев, затем по критериям дать оценку, затем ее объяснить. Ты нами пользуешься для чего? И как оцениваешь? А почему так? Удобнее уже хотя бы тем, что можно проще сегментировать людей - кому важно качество, кому цена, кому что еще. И затем оценки в сегментах уже вполне себе actionable - можно за них бороться. Открыть/Комментировать

2020-10-01 16:43:20 Время от времени все маленькие и большие начальники должны говорить свои людям обратную связь. Ну там когда человек не тянет, или делает что-то не так. Не в части, что - ну вот тут красную кнопку поменяй на синюю, а в части более общей, что “знаешь ли, не получается у тебя вот здесь”. Ну и как-то так складывается, что многим добрым и хорошим людям, особенно попавшим в эту роль не давно, особенно выделившимся прямо из этой же среды, вот им говорить другим негатив как-то не охота. Не приятно. И они этого избегают. И даже люди, которые решительно критикуют одних, могут жаться и мяться с другими.

То есть одним концом у нас индустрия страдает от “на меня матом орут”, а другим от недостаточно прямой обратной связи. Причем это ситуация класса “оба хуже”. И даже всякие методы типа “слоеный пирожок” (он же попросту “похвалить-поругать-похвалить”) не особо помогают. Все равно неприятная часть начинает замыливаться, ломаться - вот можно даже понаблюдать, что как только человек стал сбиваться, договорить долго, неконкретно, прыгать между незаконченными предложениями - он говорит что-то ему неприятное.

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

Но у кого такая проблема есть, то ее можно более-менее решить простым workaround’ом - написать эту обратную связь. Почему?

1) Потому что любой текст “не вырубишь топором”, и это обязует. Нам придется все сформулировать так, чтобы потом на наши претензии не было ответа “а что ты раньше не говорил, что код прямо совсем плохой? ты же просто сказал, что можно и получше”. Заодно запись еще и мысль в порядок приводит.
2) Потому что, написав все это, мы это должны будем переслать получателю. Но вначале поговорить. Именно вначале. И вот тут мы словами все по-человечески и расскажем, без этой письменной сухости. НО всякий раз, когда говорить что-то будет неприятно, когда захочется смягчить, замылить (есть вы будете связаны тем, что за спиной заградотрядом стоит текст, который надо будет отправить. И если мы говорим “ну тут чуточку не так”, а там написано что вообще все совсем не так, то потом будет удивление. Что это ты говорил одно, а написал другое? Так что придется соответствовать
3) И наконец надо переслать этот текст. Обязательно переслать. Это наш сожженый за спиной мост, чтобы не струсить и не убежать от неприятных слов. Это наш заградотряд, который заставит нас сделать #2 как положено;

У кого есть такая проблема, то пользуйтесь
А кстати, есть такая книжка radical candor, и там расписаны и про “оба хуже” (даже три способа делать плохо). Там они называются Obnoxious Agreesion (это когда “продолбали полимеры”) и Ruinous Empathy (это когда как-то неудобно сказать хорошему человеку прямо) Еще там написано как надо бы в идеале. У меня, правда, не всегда еще получается Открыть/Комментировать

2020-09-29 19:06:41 А перевброшу-ка я забытую классику, которую сейчас даже гуглом с трудом найти можно. Это рассказ о том, как организационно построено управление на авианосце

Краткий пересказ

Обстановка
1) Авианосец это среда, где выполняются технически сложные и опасные операции в условиях ограниченного времени и большого числа взаимодействующих сторон
2) Частые изменения не позволяют заранее выстроить все процессы, они формируются по месту итеративно.
3) Все слабо документировано в силу тех же самых частых изменений
4) на кораблях высокая текучка кадров в каждой роли из-за постоянных внутренних переназначений
5) требуется несколько недель “отладки” экипажа, чтобы новый корабль вообще мог что-то полезное делать (но медленно и мало)

Решение
1) Преемственность, системность и развитие поддерживаются главным образом ротацией корабельных старшин (читай - тимлидов), которые перекрестно опыляют своими практиками другие корабли
2) Действуют культура и практика постоянного и ежедневного обучения и совершенствования в текущем деле. Все кого-то учат и все чему-то учатся, большей частью на практике. Типичная занятость это учиться текущему делу (a), учить свою команду (б) и учиться на следующую должность (в). Это все неформально, но повседневно.
3) Коллектив находится в непрерывном жестком конфликте между “так принято” и “давайте поменяем”. Несмотря на отдельные попытки это как-то упорядочить, побеждает эволюционно-выживательный подход
4) конкретно полеты организуются не по строгой иерархии или процессу, а по “разберитесь там сами”. отсюда много споров в перекрывающихся областях ответственности. базисом решения споров является оценка, что в итоге успешная операция для всех хорошо, а проваленная - для всех плохо. в итоге получается странная ситуация - господство жестко убежденных в свой правоте людей, однако также жестко настроенных на сотрудничество
5) большинство функций так или иначе “периферийно” дублированы, хотя полновесных крупноблочных дублей часто нет. значительная часть старших офицеров не делают, а “присматривают”
6) большинство рабочих групп в норме недогружены, чтобы обеспечить дублирование при необходимости


https://govleaders.org/reliability.htm Открыть/Комментировать

2020-09-01 15:12:09 Теперь вернемся к инвентаризации - часто приходится выяснять зачем нечто сделано тем или иным образом (потому что сейчас это надо изменить). Если в компании был хотя бы минимальный процесс, то остается масса цифровых следов. Тикеты в поддержку, багрепорты, ТЗ на фичу. В крайнем случае - переписка. В одном случае, просто запаковали и забрали почтовый ящик - очень пригодилось. Поиск по цифровым следам реально работал лучше, чем спрашивать прежнюю команду.

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

Может быть это кому-то пригодится Открыть/Комментировать

2020-09-01 15:12:09 Так совпало, что в нескольких чатиках прозвучали вопросы о том, как правильно принимать/передавать дела по проекту другой команде. Вариант этого вопроса это “как правильно законсервировать проект?”.

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

Для понимая особенностей: размер кодовой базы порядка 1 млн строк, число пользователей (b2b) от нескольких тысяч до нескольких десятков тысяч. Нюанс в нашей области - все продукты коробочные, то есть развертываются на серверах клиентов. Нельзя обойтись нежным “работает - не трогай” на своих машинах - каждый раз надо распространить исправление, его развернут на тысячах самых разных машин чужие люди, и если чего пойдет не так, то будет большой вой.

В силу политических причин, все продукты пришлось передавать два раза. От исходной чужой команды - первой своей, а потом от нее другой своей же.

Массовость породила некое подобие процесса:
1) инвентаризация всех существующих ресурсов для последующего копирования. Понятно, что сюда входит репозиторий кода. Но также и багтракер, и хранилище всех документов, и форум, и чат, и история тикетов , вообще все, что можно найти и что отдадут, дистрибутивы и бинарники. Об этом еще немного позже - но это предельно важный этап. Скажу только, что однажды мы обнаружили, что кусок исходников не был на передан (по недосмотру он вообще никогда не помещался в репозиторий) и нужный компонент нашли в бинарном мусоре перебором разных файлов методом черного ящика. Один из них правильно работал по шифрованному протоколу. Фуууух, пронесло…
2) знакомство; требуем общее описание продукта, его архитектуры и принципов. Из чего вы исходили, когда что-то делали, как оно все должно работать вместе. Детали модулей можно почти всегда выяснить по коду, а вот общие принципы выявить тяжело; На хороший документ в большинстве случаев рассчитывать не приходится - вызываем главного специалиста(ов) на место и он под запись рассказывает
3) инструкция по быстрому старту. как это собрать, запустить и убедиться, что работает. До “as a code” подхода оставалось еще очень много лет, да и сейчас он еще не повсеместен. Без такой инструкции я первый принятый продукт бесплодно устанавливал три дня подряд. Про сборку даже говорить не приходится - даже про родной продукт я часто шутил, что можно безопасно допустить утечку исходников - никто не скопирует продукт, потому что собрать его по исходникам просто нереально, нужна цистерна секретного соуса. Разумеется, инструкцию надо немедленно практически проверить. На слово в этом бизнесе верить не стоит.
4) инструкция по расширению - грубо говоря, как добавить новую фичу или модуль. Берем типовую задачу и примеряем ее на код. Интересно, что если с этапа рассказа про архитектуру разработчики выходили со словами “вау! Нам бы так!”, то с прохода по коду все обычно много плевались и говорили нехорошие слова о предшественниках.
5) распросить наиболее проблемные области по текущему опыту. “что бы бы вы советовали сделать самим себе, если бы не прервались.” Инженер не может удержаться и не поговорить о проблемах, а знать слабые места критически важно
6) после воспроизведения сборки, запуска и простых изменений (1-4 недели) с большей частью исходной команды прощаются и ВСЕ управление передается новой команде. 1-3 эксперта из исходной команды остаются консультантами на почасовой оплате на срок 2-4 месяца. Новая команда раскатывает обновление и если клиенты его пережили, то крещением боем пройдено.

Теперь вернемся к инвентаризации - Открыть/Комментировать

2020-07-31 19:38:15 С некоторым удивлением всегда читаю о применении ТРИЗ к бизнес-задачам. Если вы не сталкивались с этой аббревиатурой раньше, то ТРИЗ это Теория Решения Изобретательских Задач, созданная в 1956 года Генрихом Альтшуллером. Это прямо набор конкретных принципов, абстракций и даже алгоритм, как изобрести что-то хорошее. В советское время отдельные последователи Альтшуллера регистрировали изобретения сотнями, а кто-то, помнится, и тысячу пробил.

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

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

Насколько я знаю, такой работы никто не проводил. Поэтому механический перенос принципов ТРИЗ на бизнес или выдачу каких-то собственных умозрительных принципов за “ТРИЗ для бизнеса” нельзя ставить с оригинальным ТРИЗ на одну полку.

В каком-то смысле программистские паттерны проектирования (синглтон и тп) можно воспринимать как элемент программисткого ТРИЗа, но аналогичной полной системы все-таки нет. Открыть/Комментировать

2020-06-29 12:51:13 ​​В одной торговой компании висит плакат, который стал в каком-то смысле если не моим девизом, то одной из любимейших поговорок - “невыставленный счет не может быть оплачен”

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

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

Более сложный пример - все понимают, что в продукте есть устаревшая компонента, что работа с ней это боль, но - эта боль никуда не девается. Менеджеры продолжают заводить задачи в эту компоненту. Инженеры продолжают страдать. При этом весьма вероятно, что проблему часто обсуждают, но не решают. Яркий сипмтом “кухонные разговоры” или “разговоры в курилке” - часто, подолгу, уже продолжительное время, а проблема все таже.

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

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

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

“Выставить счет” это донести проблему от тех, кто видит, но не может, к тем, кто может, но не видит.

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

В принципе, можно и выставлению “счетов” способствовать. Классическая ретроспектива это способ собрать “счета” - кто что вспомнит. Но уже на следующем шаге, все может угаснуть - потому что дальнейшие действия-счета не были выставлены.

Вобщем, выставляйте “счета” Открыть/Комментировать

2020-06-16 21:51:29 “Когда в руках молоток, всякая проблема начинает выглядеть гвоздем” - есть поговорка примерно в таком духе. Это может не так страшно, когда молоток в ваших собственных руках, но все мы временами обращаемся за помощью к специалистам. И эти специалисты вобщем-то теже самые молотки.

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

Приходит первый известный тренер, основная специализация “ценности организации” и тп - объясняю проблему. “Так они почему спорят” - говорит тренер - “потому что у них ценности разные! Сейчас мы им внедрим понимание общих ценностей и они перестанут спорить”. Не в этом же проблема была!

Приходит второй известный тренер, основная специализация “жесткое управление”. Объясняем проблему. “Так они почему спорят” - говорит тренер - “потому что в вашей организации полномочия жестко не разделены. Сейчас я вам все организую - здесь разработчики, здесь тестировщики. Здесь говорить, здесь слушать”. Опять не вышло!

И в третий раз пошел мужик в лес за елочкой, но это уже другая история

Аналогично и в быту. Какого специалиста позовешь - из такой области и решение получишь. Так, мне однажды популярно объяснили, что только операция меня спасет. Но я что-то замотался и … оно как-то без операции само прошло.

Аналогично с консультантами

Поэтому приходится принимать внешнюю помощь с большой осторожностью Открыть/Комментировать

2020-06-15 16:22:56 ​​Несколько непрофильный пост, но с другой стороны - всегда актуально понимать масштаб явлений. Одним из громаднейших плюсов курса GoPractice я видел как раз навык не боятся поиска цифр, по которым можно оценить масштаб. Но это не только product manager’ам актуально, а всем, кто должен принимать решения.

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

На помощь внезапно приходит “большой брат”. Всевозможные сервисы собирают очень много аналитики о бизнесе, а сделать поправку на их репрезентативность не так уж сложно.

Вот три графика о деятельности бизнеса в РФ
1) продукт “Мой склад” показывает почти двукратное падение в объемах продаж у бизнесов и затем линейной восстановление
2) продукт “Эвотор” (кассы) показывает примерно такую же картину
3) продукт Smartway (бронирования командировок) ожидаемо показывает более худшую ситуацию - и падение в 6+ раз и восстановление более скромное

Графики взяты из канала “Инсайды продаж” (https://t.me/salesinsides) Открыть/Комментировать