Давно ничего не читал (кроме художественного или недостойного упоминания) и не писал и вот заставил себя.
Одна из простых, казалось бы очевидных , но оттого не менее сложных вещей, которую я осознал довольно поздно, но которая давно описана - это то что коммерческая продуктовая деятельность состоит из discovery и delivery. И если про delivery нам мозги проссывали года с 2007 и теперь все кругом теперь Agile (но мы все еще не знаем чем абстрактный класс отличается от интерфейса), то с discovery как была жопа так и есть.
Определенно наблюдается некоторое движение в правильном направлении и индустрия пытается как-то формализовать свой опыт и сделать его переносимым - Jobs-to-be-Done, Customer Journey Map, etc. - но кажется это только придумывание того, как будут выглядеть буквы в алфавите. А вот книга Кагана - это собственно уже набросок самого алфавита, подчеркиваю - набросок. Книга скорее расставит в правильном порядке этапы продуктового исследования , нежели даст полную энциклопедическую картинку того что это вообще такое.
Читая книгу у меня была куча вьетнамских флешбеков о том как я что-то делал/запускал и почему оно у меня получалось/не получалось.
Что в книжке плохого? Ну она конечно переведена на русский через жопу. Структура книги тоже мне кажется могла быть лучше, но я ей это прощаю.
Еще одна шальная мысль, которую книга подселила в мой мозг - хорошее владение техниками продуктового может настолько свернуть голову в определенную сторону что тебе будет пофигу в какой отрасли исследовать продукты, ты будешь их исследовать где угодно. Исследовать, но не делать. Ну или это моя личная фобия.
Все мы умные задним умом , и ,конечно, мудрость тех или иных книжек чувствуется только после того как несколько раз выхватишь пиздюлей именно таким образом, который в книжке описан. Такое вот выхватывание побуждает тебя к прочтению большего числа книг, дабы снизить интенсивность выхватывания, но - сюрприз, сюрприз - ты все равно будешь отхватывать.
Но так как ты не один, и вокруг тебя иногда (а лучше всегда) есть молодое подрастающее поколение специалистов, то вот именно их ты можешь уберечь от типовых сортов пиздюлей. Если дашь вовремя прочитать нужную книжку и проверишь что они не только ее прочитали , но и начали что-то по ней делать.
P3.express - это сублимат практик по управлению проектами, который лучше использовать, чем не использовать, особенно тем кто менеджит проект в первый раз.
Отдельно не могу не подчеркнуть что на свои 45 страниц текста - мудрости там намного больше и подача намного лучше чем в pmbok.
Для того чтобы объяснять людям понятными словами что происходит когда вы будете им вводить в организации Engineering Ladder.
Как человек, который видел внедрение engineering ladders в нескольких организациях и в паре организаций внедрял это сам, я читал вот эту статью про офигительные приключения Netflix и периодически у меня сводило лицо.
Ситуация внутри Netflix не является какой-то особенной - она типична. Фундаментальной основой проблематики внедрения карьерных лестниц внутри организаций является человеческая же природа. В природе нет никаких карьерных лестниц (что не означает что нет иерархии), но и коллективов сходных с размерами современных IT организаций тоже нет. Тут конечно можно вспомнить про стаи саранчи, но сложность и разнообразность поведения качественно иные.
Когда у тебя есть плоская структура где каждый каждому брат и вообще Senior Software Engineer - это очень хорошо вкатывается в голову человека за счет биологии.
И именно с этим моментом конфликтует внедрение карьерных лестниц - вам нужно четко понимать что вы придете в плоский неструктурированный коллектив и скажете что кто-то теперь выше, а кто-то ниже на этой самой лестнице.
Этот момент неизбежен, к нему нужно готовится, и несмотря даже на самую тщательную подготовку вы можете выхватить нежелательных последствий.
Второй момент которому достаточно часто уделяется мало внимания на старте - это процесс перехода по карьерной лестнице. Его также придется разработать и внедрить, и объяснить всем. Лучше даже показать на примере пару тройки растущих людей. Самый частый вопрос- "а судьи кто ?" - кто конкретно принимает решение о том переходит человек на ступеньку выше или нет ?
Третье - размер. На примере Netflix - 2000 инженеров - это уже очень поздно. Даже если у вас есть аналитическая оценка того сколько человек могут встать и выйти из организации и пусть она условно 5% - то простая арифметика говорит что 5% от 2000 и 5% от 500 человек - это разный уровень потерь. И внедрение карьерной лестнице - это стратегический вопрос, тесно связанный с ростом организации.
Честно ожидания от книги не оправдались чуть более, чем полностью. Основополагающий принцип Грэма о покупке акций компаний которые недооценены - это конечно хорошо, но ... И тут вот списком из трех пунктов не отделаться. Дело в том что реальность, описанная Грэмом - еще более старая, чем реальность описанная Линчем, которого я тоже критиковал. Обе из тех реальностей - они реальности настоящих работников Wall Street, для которых копание в отчетности компаний - суть и базис ежедневной работы. С моментов написания книг мир изменился - инвестирование уже не есть удел среднего класса, банковские депозиты сходят на нет, фондовые рынки глобальны и что более важно - на них приходят обычные люди, которые не склонны заниматься фундаментальным анализом и именно поэтому махрово цветут фонды (ETF). И это цветение если не суть завтрашнего фондового рынка, то точно серьезная угроза сегодняшнему его состоянию - частное мнение на этот счет можно почитать тут.
Книжка точно избыточна по объему, хотя хорошо переведена и структурирована.
Долго мучал и наконец домучал. 256 страниц А4, с тонной воды, где есть концентрированного смысла на 1 пост в бложике (читай 5-6 листов).
Квантифицирование результатов, характеризующее достижение цели - это конечно хорошо, ибо выносит из дискуссии конфликт субъективных "все сделал" и "чот кажется не сделал", однако к описанной в книге (да и не только в книге) системе есть несколько претензий: 1. в один голос все адепты OKR говорят двухнедельных интеграциях на стыке кварталов по подведению итогов и постановке новых - выглядит жирновато. Если раз в квартал нужно две недели на постановку целей и подведение итогов, то на годовой OKR видимо потребуется со всеми ритуалами и выравниванием целей - месяц.
2. инструментарий. Это все можно вести в одном excel-файле, но кажется что если перевалить за сотню OKR (будь то подразделения или люди) при 3-5 О (целях) по 3-5 KR на каждую - вы замучаетесь листать тот excel. Первое что приходит в голову - довольной умный гибрид MindMap в смеси с excel.
3. кому все это надо/подходит. Пересмотр и постановка (возможно новых) целей каждые три месяца подходят компаниям , для которых в рамках этих 3 месяцев могут произойти значимые изменения окружающей среды на которые необходимо среагировать. С точки зрения рядового сотрудника/инженера - что обычное планирование (Management by Objectives) что OKR - все одно.
Еще одна мысль:если вы Гугл и нанимаете ну очень умных людей, которых не знаете/не умеет/не можете контролироать и пусть они себе там делают что хотят лишь бы бизнес делали а все фреймворки изобретаемые в процессе - ну это ок, уже заложено в стоимость и не повлияет на прибыль - да, кажется что OKR - это может быть способ сохранять этим умным людям продуктовый фокус. Но тоже только "может быть " потому что в performance review результаты OKR (по утверждениям) не используются.
У меня до сих пор остается подозрение что "вы не любите кошек, потому что вы просто не умеете их готовить" и если хотя бы раз увидеть как это все происходит в живую на стыке кварталов то может быть и можно будет понять в чем изюминка. Пока все равно не понял.
Оценка книги: 4/10 , ниже есть три видео которые успешно заменяют книгу.
Заметки на полях
История OKR
Фредерик Уинслоу Тейлор -
Хоторнский эффект - дело не в свете и не изменениях, а в том что к работникам проявили интерес.
Питер Друкер , Практика менеджмента - три каменщика (зарабатываю на жизнь, становлюсь лучшим в профессии, строю храм). Качать профессию - не самоцель, нужен фокус на бизнес.
Management by Objectives (Друкер)
Каждому менеджеру, начиная с «большого босса» и заканчивая начальником цеха, бригадиром и офис-менеджером, нужны четко сформулированные цели. Эти цели должны объяснять, какие результаты необходимо обеспечивать вверенному ему подразделению, а также указывать, какой вклад обязан внести менеджер и его подразделение, чтобы помочь другим структурным единицам компании выполнить поставленные перед ними цели. Наконец, они должны указывать, на какой вклад со стороны других подразделений может рассчитывать этот руководитель, чтобы достичь поставленных перед ним целей. Иными словами, с самого начала акцент в целях делается на коллективной работе и коллективных результатах.
Цели по Друкеру могут быть краткосрочными и долгосрочными, количественными и качественными.
Проблемы с MBO - насаждение сверху вниз и длительный период планирования.
Эндрю Гроув, Intel - куда я хочу попасть (Цель, O) и как я буду оценивать свое продвижения (мера результата, key result). Горизонт планирования до 3 месяцев.
Джон Дорр (фонд Kleiner Perkins) - занес OKR из Intel в Google.
Что такое OKR
OKR — это структура критического мышления и постоянная дисциплина, направленная на то, чтобы сотрудники работали вместе, сосредоточив свои усилия на внесении ощутимого вклада в развитие компании.
Структура критического мышления.
Постоянная дисциплина.
Убедитесь, что сотрудники работают вместе.
Сосредоточение усилий.
Вносите ощутимый вклад.
Цель (Objective) — это краткое изложение главной качественной цели, при- званной продвигать организацию в желаемом направлении. По сути, это вопрос «Что мы хотим сделать?». Правильно сформулированная цель имеет временное ограничение (квартал) и должна вдохновлять вашу команду и отражать ее коллективное видение.
Ключевой результат — это количественное выражение для измерения достижения цели. Если цель сводится к вопросу «Что мы хотим сделать?», то ключевой результат — «Как мы узнаем, что достигли цели?».
Самое трудное при постановке ключевых результатов — найти баланс: ключевые результаты должны быть достаточно сложными, чтобы вы получали интеллектуальное удовольствие от их достижения, но не сверхсложными, поскольку кажущаяся невыполнимость может деморализовать команду.
Ключевой результат может быть базового уровня (первый раз формулируем что хотим поэтому не понимаем где база и полученное будем считать за нее), позитивной метрикой (повысить на 20%), негативной метрикой (сократить на 20%), метрикой пороговых значений (между 20% и 30%) и вехой (запустили фичу в 3 странах-0.7, в 2-х - 0.5, в 1-ой - 0.3).
5 мифов реализации стратегии :
Реализация — это согласованность. Каскадирование целей сверху вниз создает функциональные колодцы, которые действуют в собственных интересах.
Реализация означает следование плану . Пока не столкнутся с реальностью. Нужно реагировать на изменение среды, а не следовать плану.
Коммуникация — это понимание. коммуникация доходит не до всех и не одинаково.
Культура результативности стимулирует реализацию. Бешеная результативность приводит к локлаьным перекосам.
Реализация OKR должна осуществляться сверху вниз. Ровно наоборот.
Нельзя сказать что прочтение этой книги намного лучше чем прочтение оригинального документа, но скорее нагрузит вас контекстом для оригинального документа.
В культуре Netflix нет ничего прям особенного - это просто управление без хуйни - вы убираете все ненужное, что может сковывать свободу действий людей в инновационной компании работающей на развлекательном рынке. Так можно сделать еще много где, но много где так сделать нельзя - и об этом в книге тоже говорят прямым текстом. Так же, всем адептам культуры Freedom & Responsibility настоятельно рекомендую обратить внимание на целую массу мест в книге где чаще всего Рид говорит о том что "не все везде и всегда, а кое-что иногда и местами" - адаптация некоторых практик внутри самой организации неравномерна (и это приходится подстегивать) и есть резервные механизмы управления (из опыта предыдущего управления), которые всегда можно включить.
Пожалуй самыми ценными для среднестатистического менеджера в ИТ (классический читатель этой книги) на мой взгляд будут две мысли: 1. уберите посредственностей/мудаков из команды - это как раз тот самый случай когда 2+2 будет давать даже не 5 , а 6.
2. Контролировать умных людей все равно нужно, но дав им достаточное информационное поле для принятия решений и возложив на них ответственность - делать это можно сильно реже и/или выборочно.
Книга хорошо структурирована и качественно переведена.
Я читал эту книгу очень долго и причин тому две : 1. очень мелкий шрифт - я думаю это сделано специально. ибо если ее издать с нормальным размером шрифта, то она превратиться в 800 страничный фолиант и хер ее продашь.
2. отвратительный язык изложения и постоянные качели в нем - то читаешь и приятно-интересно, то блевать хочется.
Эта книга объяснит вам некоторые элементы теории игр, некоторые моменты про стратегию вообще и в частности, но не объяснит ничего из этого вглубь (гораздо лучше, хоть и менее красочно с этим справится Алексей Савватеев на YouTube), зато покажет вам кучу экономических примеров того как стратегия и игры воплощаются в жизни.
Если хочется прикоснуться к теории игр и стратегиям. но не хочется в математику - рекомендую, во всех остальных случаях - нет.
Как я уже писал в своем опусе о GTD вообще я пользовался MaxDone и пришло время его менять. Чтиво ниже - оно про мой конкретный переезд с MaxDone на Todoist, события ему предшествовавшие и выводы по ходу.
Часть первая - щелчок.
В дампе данных из MaxDone я выяснил, что первая завершенная задача осела в его закромах аж в ноябре 2014 года. Что же заставило меня с него мигрировать? Причины на самом деле три, хотя их можно сократить до двух: 1. 29 июня 2020 сервис прилег и так как я лично знаком с людьми, которые его начинали делать я просто пошел в личку и его приподняли.
В этот момент собственно говоря сознание и дало трещину - с одной стороны ты не видишь своих задач и мозг думает что их нет, но спустя 15 минут, когда допамин с серотонином успокоились приходит отрезвление и осознание того что они на самом деле есть.
2. Листая ленту Twitter я увидел вот такое вот и щелчок сфинктера произошел второй раз.
Перейдя по ссылке я узнал новых деталей на тему того что проект не будет поддерживаться дальше и что ситуаиця описанная в п.1 может повторится с более печальным исходом.
3. Перед новым годом я разжился Samsung Galaxy S20 с 11 версией Android на котором виджет Maxdone отказался работать и показывать актуальные таски от слова совсем, но это скорее было уже последней каплей, нежели причиной.
Тут можно сразу отложить первые два вывода: 1. если в системе task-менеджмента нет возможности экспорта тасков или на худой конец API, чтобы этот экспорт сделать самому, то вы оказываетесь в ситуации классического vendor lock-in и вам будет плохо.
2. бэкапы. Тут много всего можно написать, но первое - они должны быть, и второе - в них нужно хотя бы разок посмотреть , что там отклаывается, и третье - лучше чтобы они это делали в какую-то независимую площадку.
В качестве независимой площадки для бэкапов сделанных задач я выбрал Google Docs и настроил туда отгрузку через Integromat - хотел сначала telegram, но не все так просто как хотелось бы.
Часть вторая - выбор новой системы.
Собственно, поиски новой системы начались несколько раньше - после первого и второго прецедентов я стал смотреть на то что есть на рынке. Что входил в рассмотрение 1. Microsoft Todo (ex. Wunderlist) - попробовал , интерфейс и возможности показались дико примитивными/неспециализированными. Видео от Дорофеева тут.
2. Todoist - слышал отличные отзывы от друга, решил смотреть.
3. SingularityApp - еще один проект который пиарит Максим Дорофеев (как и MaxDone). Видео от Дорофеева тут. Показалось аналогом todoist, c минорными изменениями UI и всякими ненужными мне pomodoro-фичами.
Основным бичом всех инструментов после MaxDone стали ... выполненные задачи. В отличии от MaxDone который просто отображает их все одной портянкой, Todoist и Singularity предполагают более неудобный принцип работы. В Todoist вы найдете все, но в журнале активности, а в Singularity - в архиве.
Надо сказать что эти отличия всегда будут вкусовщиной и тут следующий вывод:
при выборе инструмента нужно учитывать свои личные предпочтения.
Еще один момент, который меня сначала триггерил, а потом даже понравилось - в todoist найти задачу вне проекта - сложно, а если она в проекте - то легко. Это дает более сильно выраженный проектный фокус, что кажется даже хорошо.
Третий момент который мне нравится в Todoist сейчас - это то что ты можешь посмотреть свои задачи на произвольный день в календаре - то есть когда ты перекидываешь задачи с понедельника на четверг, потом наступает четверг и ты понимаешь что у тебя их на четверг уже 25 и все надо именно сейчас (в четверг) - ну это довольно неприятный "ой", который эта вот фича может предотвратить.
Часть третья - миграция
Тут все будет довольно скучно и по-менеджерски. Вместо того чтобы писать красивые скрипты миграции и долго дебажиться, я просто экспортировал все незавершенные задачи в CSV , переделал их в другой CSV и импортировал в Todoist. Нюанс - у Todoist нет глобального импорта задач, есть только попроектный, поэтому я разрезал задачи на "сегодня", "неделю" и "может-быть когда-нибудь потом" на три разных проекта с этими самыми названиями и потом уже растаскивал их по проектам в соответствии со спецификой Todoist. Кстати проект "может быть, когда-нибудь потом" до сих пор не растащил до конца))).
Что еще нужно сказать про текущую систему в сравнении с предыдущей? Проекты в MaxDone снабжены статусом (in progress, planning, completed, canceled, paused) и сроками, но оба эти аттрибута чуть менее чем полностью нефункциональны там и более носят статус заметок на полях, нежели чего-то рабочего - если сроки проекта уже прошли MaxDone не начнет орать дурниной, равно как и todoist, но у него этих аттрибутов и нет.
Из приятных мелочей - простецкая аналитика количества выполненных задач в todoist - я знаю что в среднем у меня 12 выполненных задач в день и можно его настроить на эту цифру , чтобы когда червь сомнения начнет тебя грызть изнутри - можно было посмотреть на счетчик и успокоится (Конечно, задачи все надо записывать, но это везде так).
Выполненные задачи из MaxDone я выгрузил как справочную информацию, спасибо заметке на форуме у Максима Дорофеева и тему что у MaxDone нет лимитов и все свои 14000+ тасков я смог выгрузить одним куском json-а, но опять же - парсить его я не очень собираюсь, больше лежит как бэкап для справочной информации, за которой я скорее сначала пойду в пока еще работающий MaxDone нежели в json у себя на компе но мысль о том чтобы сделать из этого на каком-нибудь bootstrap статическую страничку набитую данными с фильтрацией и поиском или отложить в табличном виде в Google Docs у меня есть.
MaxDone спасибо, с ним было хорошо, при том довольно долгое время. Про todoist напишем когда-нибудь потом, когда придется съезжать с него.
Основной залог спокойного переезда - малое количество задач (у меня было чуть больше 300 и кажется что многие в системе управления задачами лежать не должны).
Вот уже много лет у меня в бэклоге лежит задачка-желание написать говно-пост про идеи и креативность. Почему лежит и не делается ? Потому что в какой-то момент в прошлом я посмотрел видео Скотта Беркуна и понял, что мне еще рано рассуждать на эту тему, можно еще людей послушать.
Видео вот
Тем не менее, Скотт был менеджером проектов в Microsoft, и увидев что его книга переведена на русский я не мог пройти мимо.
Книга структурирована на 3 части , 16 глав. Автор прямым текстом в начале говорит, что главы можно читать независимо друг от друга, но это не так - в тексте есть куча отсылок на другие главы, при том чаще дальше по содержанию книги чем назад.
На 560 страниц довольно много воды, абстрактных примеров и слоганов Тони Роббинса.
Про "практику проектного менеджмента" - вообще в книге не нашел.
Скотт занимался в Microsoft разработкой Internet Explorer и я готов поверить что в MS для проектов уровня Internet Explorer есть такой документ (оформленный как документ) как продуктовое видение, есть маркетинговая стратегия и даже строятся WBS (work breakdown structure). Проблема в том, что в российском ландшафте управления проектами вы этих артефактов с высокой долей вероятности не увидите, а если и увидите то не факт что качественные.
Более того - мне кажется половина практик описанных Скоттом из той эпохи когда софтверные проекты делались годами, agile был в новинку - вторая половина 90-х и начало 2000-ых. С тех пор много чего поменялось.
В книге есть полезные приемы, но и тут вопрос - если вы реально управляете проектом по разработке софта и не знаете как проводить встречи, писать письма, трекать прогресс - то может быть вам и будет полезно, но страшно за ваш проект. Одним из плюсов все-таки является большая библиография источников автора - я себе оттуда пару книг записал.
Трудно даже сказать сколько лет эта книга пылилась у меня в списке на прочтение (да, моя антибиблиотека очень велика).
"Если долго мучаться, что-нибудь получится" - гласит народная мудрость.
Если вы много и системно занимаетесь чем-то, то у вас внутри вырабатывается система. Если вы занимаетесь этим своим чем-то ну очень успешно, то выработанную вами систему можно попробовать продавать отдельно, даже отдельно от результатов ее функционирования.
Например Уильям Детмер много упарывался по теории ограничений Голдратта и потому выродил из себя книгу по инструментам теории ограничений, прочитав которую вы узнаете что на самом деле есть 7 нотаций, следуя которым если вы будете правильно описывать свои проблемы, то можете найти что-то интересное, чего не замечали ранее.
Примерно тоже самое и с теорией решений изобретательских задач - если долго анализировать патентный фонд , то можно начать находить схожие закономерности в изобретениях различного рода. В этих закономерностях можно углядеть некоторые принципы, может быть даже описать законы. Вопрос лишь в том - будет ли жить дальше твоя система, отдельно от тебя отца-основателя или нет? В случае с Дэвидом Алленом и его GTD - можно сказать , что да. В случае с ТРИЗ - наверное нет. И причиной тому всего лишь историческая случайность. Описанная в книге теория весьма интересна, к тому же подкреплена кучей ссылок на патенты и авторские свидетельства. Однако в мире она почему-то не прижилась. Точнее прижилась ограниченно, исключительно в области материального производства (хотя и это уже неплохо).
Если бы исследования патентного фонда, составлявшие основу ТРИЗ проводились с государственным масштабом и за государственный счет может быть удалось бы нечто больше и долгоиграющее, в том числе для ИТ.
Книга скорее представляет собой высокоуровневый обзор + шпаргалку по основным моментам ТРИЗ. Назвать ее совершенно бесполезной конечно нельзя - автор таки набрел на понятие психологической инерции, которая мешает изобретательству, и некоторые техники ее устранения. Даже разработал пошаговый алгоритм решения изобретательской задачи (хотя на самом деле нет), который вводит понятия мини(макси)-задачи, оперативной зоны и оперативного времени, которые полезны и сейчас. Но вот ощущения большой единой системы, которую можно было бы сейчас применить к ИТ у меня содержимое теории не оставило.
Заметок на полях не будет (они у меня есть , но выглядят крайне сумбурно), ибо книга структурирована отвратительно (да. в СССР не умели "продавать").
Оценка: 5/10. Тот же самый Харари "почешет" ваш мозг лучше.
