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

С другой стороны, под видом agile часто происходит откровенный хаос и бардак. Возникает дефицит анализа, продумывания, структурирования, правил и прочего "старорежимного барахла". Возникает господство "и так сойдет".

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

Но были проекты, слишком сложные и неопределенные для все продумать заранее, и одновременно умные и компетентные люди успешно преодолевали возникающую сложность. Для таких высокопрофессиональных команд и был предложен Agile Manifesto. В нем это прямо не написано, но это следует из контекста его создания.

Однако, те же самые приемы отлично легли и на низко-профессиональные команды. Качественные управление и анализ были и остаются плохо-масштабируемым дефицитом. И agile методы поддержали быстро растущую цифровизацию не совсем в том, для чего были задуманы. Куча людей создают какой-то приемлемый (но не оптимальный результат) ценой избыточных итераций. Это создает негативную ауру вокруг agile.

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

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

Минутка славы всех ПМов, кто вышли из тестировщиков. Согласен с оценкой @pm_god (скромно - потому что я сам из "этих"!). Там есть и про ПМов иного происхождения в соседних постах

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

самая лучшая школа это имхо поддержка (впитать боль), тестирование (важность порядка) и потом ПМ

понятно, что это условно верно в отношениии больших групп и ничего не говорит про каждого в отдельности. личная вариативность огромна

📌 тестировщики

Из тестеров получаются одни из лучших ПМов, что я встречал. Думаю, так происходит по двум причинам:

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

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

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

Дело в том, что действительно часто встречается проблема культуры "у матросов нет вопросов". Спрашивать стремно, можешь показаться глупым, так что ну его нафиг. Как результат будем делать что-то не то и получим неправильный результат. Поэтому важно поддерживать культуру, где непонятное принято спрашивать.

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

И тут встает сложный выбор - на какой из двух стульев стул сесть и как быть?

1) Ни в коем случае не возвращаться к культуре "у матросов нет вопросов". Это нижний уровень пирамиды. Обсмеять вопрос или автора вопроса - и мы скатились вниз.
2) Аккуратно вернуть ответственность за ответы, которые вообще-то в компетенции вопрошающего. "А как же я буду ...? - Это твоя область. Тебе и решать. Подумай как и обсудим предложенные тобой варианты"
3) Аккуратно приучить самим разбираться с большей частью домыслов о крайних случаях. "А что если я выйду за сигаретами в июле и тут же наступит зима?". "Запиши свои вопросы и наиболее логичные ответы к ним с твоей точки зрения. Потом сверимся". Почти всегда переход к рациональному мышлению демонстрирует, что все эти вопросы не имеют особого смысла, а такие ситуации или решаются на месте или реально невероятны.
4) аккуратно приучить предполагать наиболее вероятные ответы на простые вопросы за пределами основной области компетентности. По той же схеме, что и №3. Недавно этот прием позволил одной из команд сделать фичу, не дожидаясь ответов от временно отсутствующего менеджера. Хоть у них и не было всего объема информации о стоящих требованиях, но на широкий пласт вопросов об ожиданиях пользователя можно ответить из здравого смысла и имеющегося опыта. Чем лучше люди понимают область, в которой они работают, чем легче решать вопросы за пределами своей узкой функции.

Задавать вопросы должно быть нормальным. Но одновременно должно быть нормальным сохранять ответственность за свою область, делать "домашнюю работу" и "ориентироваться на местности".

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

Совершенно непрофильный пост о коронавирусе. Воспринимайте его как braindump и игнорируйте

Ежедневно сталкиваюсь с двумя полярными мнениями
А. “Это просто грипп!”
Б. “Мы все умрем!”
Оба мнения считаю ошибочными (и, разумеется, получу сейчас лещей с обеих сторон)

Теперь ссылки и факты
1) вирус официально называется SARS-CoV-2 (а до того часто называли 2019-nCoV, что означало “новый коронавирус); Болезнь называется Covid-19; Просто чтобы не путаться
2) он близкий родственник прошлой атипичной пневмонии (SARS)

Далее разберем пункт А

⁠Часть 1. Нет, это не “просто грипп”.
Часто еще звучит, что “от гриппа умирают 500 тыс, а от коронавируса всего-то 4 тысячи, а столько шуму!”
Почему это ошибочное мнение:
3) Всякая инфекция характеризуется двумя числами - заразностью и смертельностью.
4) От заразности зависит сколько человек будет инфицировано. К примеру, грипп не очень уж заразный, и в США им в год болеют 30-50 млн человек. То есть где-то каждый 6-10й.
5) От смертельности зависит сколько умрут. Обычный грипп убивает 0.1% (одного из тысячи). Испанка убивала каждого 10го. Бубонная чума убивает 9 из 10. Грипп убивает в мире 300-700 тысяч человек в год (это основное исследование и ВОЗ пользуется тоже им).
ВОЗ оценивает смертность SARS-CoV-2 в 3.4%
6) SARS-CoV-2 сейчас считается примерно в два раза заразнее гриппа и в 34 раза смертельнее (оценки смертности разнятся и об этом ниже)
7) Таким образом, если бы SARS-CoV-2 заразил столько же людей, сколько грипп (порядка 600 миллионов человек), то в год умрут не 300-700 тыс как от гриппа, а 10-23 млн человек, что приближается к масштабам легендарной “испанки” 1918 года
8) Вся “пустая шумиха в СМИ” вызвана опасением последствий, если вирус поразит значительные массы людей
9) Это усугубляется тем, что 1% больных нужно для выживания очень серьезная поддерживающая терапия. Доступность которой ограничена. Например в США такую терапию можно предоставить примерно 1000 человек одновременно. Если тяжелых больных будет больше и сил не хватит - каждый избыточный тяжелый случай будет умирать. Отсюда есть движение FlattenTheCurve - сдержать распространение, чтобы одномоментно тяжелых больных было немного
10) https://coronainfo.xyz тут можно наглядно увидеть, что SARS-CoV-2 распространяется и убивает намного быстрее чем свиной грипп или атипичная пневмония до него. Картина ниже
11) После вспышки в Италии ощущение ложной победы уже наверное подвыветрилось, но даже ранее https://coronainfo.xyz показывал, что кажущаяся стабилизация это чисто китайский результат. Его масштаб (еще недавно больший, чем весь остальной мир) скрывал, что за пределами Китая число случаев стремительно росло

​​Дополнение:

12) Смертность от SARS-CoV-2 в разных источниках варьируется. Причина тому, что есть две формулы -

= Умершие/Заболевшие

и =Умершие/(Умершие+Исцелившиеся)

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

Первая формула занижает - потому что кто-то уже болеет и умрет, но еще нет. А вторая формула завышает, потому что не всех выживших уже переписали в исцелившиеся. Когда эпидемия кончится, то эти две величины совпадут (картинка ниже). Данные по разным территориям плюс две разные методики дают разброс смертности 1-5%. Подробно механика расписаназдесь

13) Если не лень много читать, то стоит статью из пункта выше прочесть целиком с интересными расчетами. В частности, в ней выявлен момент, что многие страны могут на первых этапах занижать число больных на порядок (не со зла, а нюанс подсчетов). Так Китай полагал что у него 444 больных, когда их было уже 12 000. Истинное число можно прикинуть математической моделью от числа умерших (если они уже есть).

Резюме для ленивых:

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

Иллюстрации с https://coronainfo.xyz/ о динамике вируса (быстрый рост в мире) и динамике относительно известных вирусов недавнего прошлого (атипичная пневмония и свиной грипп)

Вернёмся к обычным темам. Есть тысяча способов поделить людей на группы по какому-то критерию. У меня есть своя личная совершенно антинаучная классификация:

Я делю людей на
* бабочки
* ракеты
* бульдозеры
Это не покрывает всех людей на свете, а лишь тех, кто мне актуален.

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

«Ракеты» мчатся к цели сквозь космос. Они очень быстро могут преодолеть огромные расстояния и попасть за неделю туда, куда казалось и за 100 лет не дойти. Но им нужны бесперебойное поступление топлива в изобилии и чтобы не было препятствий. Об препятствия они взрываются, а от дефицита топлива падают. Сломанная ракета лететь уже не может :( но даже половина пути некоторых из моих «погибших ракет» и оставленные ими вымпелы на далеких астероидах и спустя 5+ лет кажутся серьезным достижением.

«Бульдозеры» делают дело медленно, но неумолимо. Объём труда и препятствия их не смущают. Непогода может притормозить их, но не отменяет сделанного.

Я лично наибольший комфорт испытываю с «бульдозерами», хотя могу раздражаться на их медленность. Но никакой «юнит» не универсален:
* «Ракета» очень сложна в обслуживании, но может сэкономить годы времени. Даже однократно применённая.
* «Бабочки» могут ничего не принести в сложном климате, если их не «пасти». Но можно многого добиться, используя «бульдозеры» для ликвидации препятствий и закрепления результата.
* «Бульдозеры» могут простаивать или грести не туда. Но "ракеты" и "бабочки" могут указать нужный путь.

Все совпадения с реальными людьми под их личную ответственность!

⁠Вынесу в публичное пространство внутренние субъективные заметки о подготовке докладчика к выступлению

Классическая и КРАЙНЕ РЕКОМЕНДУЕМАЯ к прочтению книга о презентациях в целом это А. Каптерев. Мастерство Презентации. В ней есть все нужное и нет ничего лишнего. Кроме того она отличный образец оформления книги как таковой и развивает чувство прекрасного

В начале -
- ИЗБЕГАТЬ: В целом, аудитории не очень интересны подробные регалии и биография докладчика, кроме случаев когда они имеют непосредственное отношение к теме и содержанию доклада, и ровно в том объеме, который необходим для понимания доклада.
- ИЗБЕГАТЬ: Аудитории не очень интересны извинения и кокетничество докладчика о том, что было мало времени, что тема новая, и тому подобное. Краткое упоминание вскользь, это максимум что можно себе позволить при условии органичного вплетения этого фрагмента во введение в целом.

По ходу доклада
- СЛЕДИТЬ: Когда-то вопросы к залу казались верхом мастерства, но сейчас аудитория уже прекрасно видит, когда вопросы задаются для галочки. Вопросы в зал это хороший инструмент управления вниманием, но ОБЯЗАТЕЛЬНО должны предусматривать какое-то развитие со стороны докладчика после ответов. Аудитория должна увидеть явный ответ на свой немой вопрос "Ну вот ты спросил - и что дальше то?"
- СЛЕДИТЬ: Как правило, аудитория напрягается, если докладчик долго говорит про один слайд, и потом начинает быстро прыгать между другими слайдами. Желательно иметь примерно равный объем на каждый слайд. Где-то укоротить/дополнить рассказ, а где-то подрезать/дополнить слайды. Важен ровный РИТМ

Слайды

- СЛЕДИТЬ: Графика действительно отлично привлекает внимание и создает нужный фон для рассказа, но если графика идет без текста, то слайды не имеют смысла без рассказчика. Я лично считаю хорошим стилем, когда пролистывание слайдов уже само по себе способно рассказать какую-то историю (slidecast). Это требует правильного баланса между графикой и текстом.

взгляните на классику Смерть через Powerpoint как на пример оформления и баланса графики с текстом. Достаточно пролистать, чтобы понять все.

- СЛЕДИТЬ: Для правильного восприятия графиков критически важно чтобы:
- диаграмма транслировала ясную историю. Взглянул и понял
- и легко читалась (следствие из первого)
Неудачно подобранный график может "сломать" доклад, если аудитория не приняла его как аргумент. "Непонятно" всегда тоже самое, что "несогласны".

Ясный график требует
- правильного подбора формата (столбчатый / линейный / круглосекционный)
- правильного подбора цветов (к примеру ошибкой будет изобразить "хорошие" данные красным, а "плохие" зеленым)
- ликвидации ненужных деталей - лишние данные займут внимание аудитории и она построит массу ложных выводов)

Классическая и рекомендуемая к прочтению книга это Eduard Tufte, The Visual Display of Quantitative Information.

Иллюстрация забавно неудачной диаграммы ниже (реальный пример)

Довольно часто в попытке убедить или договориться, люди тратят силы на убеждение или переговоры с неправильным человеком. Частный случай "проблема лейтенанта".

К чему она сводится:
-есть человек, который принимает решения (ЛПР), которые вас касаются
- если бы вы общались с ним напрямую, то вы могли бы с ним обсудать иные способы достичь его целей, которые были бы вам удобнее. Этот человек мог бы сравнить выгоды и цены разных вариантов, сопоставить риски и потому его можно убедить. win-win, все дела
- но вот он поручает исполнение своего решения "лейтенанту". "Лейтенант" не понимает всего пространства решений, всех выгод и рисков. Он либо добивается исполнения и тогда он молодец, либо не добивается и тогда он плохой.
- вести переговоры с "лейтенантом" малоэффективно - все альтернативы для него заведомо плохие
Упс!

Многие этого не понимают, и сжигают килокалории аргументов вхолостую.

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

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

Давно не брал я в руки шашек… то есть давно не писал сюда. А тема сегодня “manage up”.

Недавно мы проводили опрос об обставноке в отделе и в частности спрашивали насколько легко выражать несогласие с руководителем. Один из отзывов был про меня лично: “если позиции не принципиально различны то договорить требует усилия, но не сложно. в противном случае *изменить мнение/позицию лидера можно только когда он сам придет после какого-то времени и накопления критической массы информации*. это либо приводит к  избыточным усилиям при убеждении, либо (что чаще) оставляется до момента набора критической массы информации”.

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

Этот отзыв побуждает обсудить концепцию “manage up”, которая у нас мало известна. Все понимают про “manage down” - сотрудникам надо ставить ясные задачи, мотивировать их, есть тысячи книг, сотни методов, куча курсов, Стратоплан и все остальное. Но, оказывается, готовить надо уметь не только сотрудников, но и босса. Сюрприз! Это и есть “manage up”.

Отзыв как раз удачно раскрывает в чем состоит manage up - руководителя трудно в чем-то убедить пока он не наберет критическую массу информацию! То есть чтобы его убедить … надо ему эту критическую массу предоставить! Мнение, неподкрепленное критической массой информации (фактами), к сожалению, часто оказывается недостаточно убедительно.

Обратимся к классике
1) известная цитата “Everyone is entitled to his own opinion, but not his own facts.” - не совсем следствие, но тонкий намек, что факты у нас должны быть общими, чтобы наши мнения вообще можно было сопоставлять
2) фундаментальная ошибка аттрибуции - действия других людей, кажутся вызванными их внутренними качествами, а собственные действия - внешними обстоятельствами. Внешним обстоятельством можно полагать и наш контекст, известные нам факты.

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

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

Здесь может возникнуть вопрос “зачем нанимать профессионала и не следовать его мнению? зачем корячиться с обоснованиями?” Нам всем очень лестно видеть себя профессионалами, однако наш профессионализм тестируется как раз способностью коротко и полно что-то объяснить. Помните анекдот “… я вам столько раз объяснил, что уже даже сам понял”? - да, только отличное понимание темы позволяет доносить мысль в короткой и одновременно полной форме.

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

Итого:
1) боссом можно и нужно управлять
2) управляют боссом (лучше всего!) через донесение информации
3) донесение информации надо уметь делать правильно

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

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

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

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

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

Графики взяты из канала “Инсайды продаж” (https://yangx.top/salesinsides)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Вобщем, выставляйте “счета”

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

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

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

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

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

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

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

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

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

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

Теперь вернемся к инвентаризации -

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

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

Может быть это кому-то пригодится