Недавно, совершенно случайно, с подачи одного хорошего человека, родилась идея — к каждой статье прикладывать краткое содержание. Не аннотацию, не завлекаловку, а именно краткое содержание. Такое, чтобы можно было статью не читать вообще.
Я попробовал, и мне жутко понравилось. Но это пофиг — главное, что понравилось читателям. Начали возвращаться те, кто давно перестал читать, заклеймив меня графоманом. И другой хороший человек посоветовал написать краткое содержание для каждой старой статьи. Я согласился и теперь, между делом, пишу эти коротышки. Назвал их шортами.
Вашему вниманию предлагаю несколько таких шортов, по нескольким публикациям. Вдруг что-то полезное для себя найдете.
Совещания очень часто проходят безрезультатно. Собрались, потрепались, разошлись.
Результаты, или продукты совещания — это решения. Вот их обычно и нет. А если есть, то не всегда хорошего качества.
Если совещание ограничено по времени, и решение надо принять обязательно, то оно (решение) бывает низкого качества.
Если совещание не ограничено по времени, и длится до принятия решения, то принимается любое решение, лишь бы закончилось совещание.
Если решение придумано на совещании, то будет принято оно — просто потому, что мозг ценит то, что придумал.
Понимание низкого качества решения придет позже, но будет уже поздно.
Чтобы принять эффективное решение, лучше не участвовать в обсуждении, а молча наблюдать.
Во-первых, мозг не будет занят придумыванием ответов.
Во-вторых, не давит необходимость принять решение.
После окончания совещания можно спокойно обдумать и принять решение. Оно будет более качественным.
Ключевое: на совещании молчать и слушать. Чтобы окружающие не переживали, сказать, что это осознанная позиция.
→ habr.com/ru/post/341654
Принципиально есть два подхода к постановке задач и контролю исполнения: паразитарный и симбиотический.
Симбиотический подход — сделать так, чтобы задача была решена.
Паразитарный подход — сделать так, чтобы задача НЕ была решена.
Симбиотический подход прямой и незамысловатый, но сложный в реализации. Поэтому встречается редко.
Задача ставится так, чтобы было понятно всё — и цели, и ресурсы, и ограничения.
Контроль осуществляется так, чтобы задача точно была решена.
Симбиотический подход — это оставлять часть ответственности (причем, бОльшую) за решение задачи на постановщике.
Паразитарный подход витиеватый и хитровыдуманный, но простой в реализации. Поэтому встречается часто.
Задача ставится так, чтобы не было понятно ничего. Чем меньше понятно, тем лучше.
Контроль, желательно, не осуществлять вообще.
Никакой ответственности на постановщике задачи нет, вся «обезьяна» пересаживается на шею исполнителя.
Цель паразитрного подхода: манипуляция, ЧСВ, самоутверждение. Поэтому часто встречается в работе наставников с начинающими сотрудниками.
Лучше, конечно, симбиотический подход.
→ habr.com/ru/post/343696
Если оценивать процесс и результаты своей деятельности без измерений, то всё время будете ошибаться.
Оценка без цифр зависит от настроения. Плохое настроение — будет казаться, что вы плохо работаете. Хорошее настроение — наоборот.
Так можно неделю сидеть и плохо работать, а в пятницу выдать «на гора» результат, и будет казаться, что вся неделя прошла хорошо.
Принципиально, есть два типа метрик: количественные и альтернативные (более известные программистам как Булево).
«Задача выполнена в срок» — это Булево. Это то же самое, что «Деталь годная» (альтернативный признак качества, когда не могут измерить в цифрах).
«Мы работаем хорошо», «Мы выполняем план», «Я — молодец» — тоже Булево.
На оценках типа Булево процесс управления построить сложно. Рекомендуется как можно быстрее перейти к количественным метрикам.
Булево порождает бюрократию и формализм. Например, выполнения задач в срок можно добиться, увеличивая сроки, придумывая себе задачи, осуществляя ИБД.
Чтобы управлять на основе Булевых показателей, надо тратить много времени — на совещания, анализ и т.д. Потому что информации слишком мало.
Рекомендуется измерять и процесс, и результат. Тогда картина будет наиболее полной.
Для программистов рекомендуется метод «Покер планирования» из Скрама.
→ habr.com/ru/post/343910
Допустим, вы — программист, и вам принесли серьезную задачу. А вы считаете, что задачу решать не надо — глупая она, вредная.
Типичное поведение в такой ситуации: вывести задачу в публичное поле. Отправить согласовывать с начальником, внутренний проект запустить, в системе зафиксировать и т.д.
На этом месте всё ломается. Человек, который принес задачу, не хочет, чтобы его считали дураком. А раз вышли в публичное поле, будет защищаться.
Человеку важно не потерять лицо, в политическом смысле. Главное в политике — никогда не признавать своих ошибок. Можно ничего не делать, но главное — не иметь признанных ошибок.
Человек приложит все силы, чтобы доказать, что программист — злодей, идиот, противник перемен. И программисту всё равно придется решить задачу.
В некоторых случаях человек устроит всё так, чтобы программист не решил задачу вообще. Тогда человек будет «белым», а программист — абсолютно «черным» (и сопротивлялся, и не справился в итоге).
Решений несколько.
Первое — стать бизнес-программистом, разобраться в смежных областях, и самому определять, что и как там надо автоматизировать.
Второе — статья Главным по изменениям. Например, директором по развитию.
Третье — не возникать, и просто делать то, что говорят.
Четвертое — Путь Спарты, быстрая отбраковка решений. Более известен, как fail fast, fail cheap (проваливайся быстро, проваливайся дешево).
Главное — не включать публичность. Сказать человеку — давай не будем тратить много времени, сделаем прототип, и посмотрим, жизнеспособно решение, или нет.
На прототип уйдет немного времени. В случае удачи оба получат свое — и решение нормальное, и политические баллы.
В случае неудачи никто не пострадает. Ну и человек будет к программисту лучше относиться.
→ habr.com/ru/post/344650
Бизнес не любит 1С и ее продукты, веб-разработчиков, СМК, бухучет, экономистов, проекты развития, Scrum, ТОС, контроллинг, KPI и системы мотивации.
Бизнес любит повышение прибыльности за счет автоматизации, рост оборота от продвижения в интернете, повышение качества продукции, простую и понятную картину бизнеса в цифрах, прогнозы состояния компании, реальное повышение эффективности, ускорение выполнения проектов в 2-4 раза, кратное увеличение прибыли и снижение запасов, точную систему управления, четкую и понятную систему оценки положения дел в бизнесе, систему оценки труда, позволяющую уволить половину менеджеров.
Бизнес любит достижения бизнес-целей. Бизнес не любит суррогатов.
Суррогат — это когда просили достичь бизнес-цели, а получили проект автоматизации, сайт, кипу бумаги, штат непонятных сотрудников или нечитаемые портянки-отчеты.
Суррогат — это когда цель по дороге заменили средством достижения. А про цель дружно забыли.
Производство суррогатов зиждется на трех китах: формализм, постепенность и круговая порука.
Формализм — это перенос целей на бумагу с декомпозицией. А по сути — перевод фокуса внимания с большой цели на мелкие детали. Про цель уже никто не помнит — все обсуждают детали.
Постепенность — это низкая скорость перехода от целей к средствам. Поначалу цель еще иногда обсуждается. Но постепенно, шаг за шагом, упоминается всё реже. Пока заказчик сам про нее не забудет, потонув в деталях.
Круговая порука — в том, что все подрядчики действуют примерно одинаково. Нет ни одного автоматизатора, который реально увеличивает прибыль. Поэтому у заказчика особо и выхода-то нет.
Чего делать?
Избегать суррогатов и первого шага на пути к их созданию: формализма. Хотя бы на внутренних проектах. Ставьте цель и разговаривайте с исполнителем о ней постоянно. О масштабах, ресурсах, планах и т.д. — тоже. Но главное — о цели.
Иначе фокус внимания непременно сместится, и вы получите очередной суррогат.
→ habr.com/ru/post/344844
Есть такой боксер — Владимир Кличко. У него есть особенность — постоянное использование джеба. Ну т.е. более постоянное, чем у других боксеров.
Джеб постоянно держит соперника в напряжении, выматывает.
Ключевые особенности джеба Кличко: простота исполнения (относительная, разумеется) и постоянство.
О том, что постоянно выполняемые, полезные, но простые действия могут принести много пользы, говорят многие авторы.
Я тоже решил попробовать. Сделал простенькую систему учета — какие джебы я сегодня сделал.
Дело было на заводе. Джебы делал в обед (я не обедаю), т.е. 1 час в день. Делал то, что другие не делают (говорят, это приводит к успеху).
Настраивал проверки самообучаемой системы, придумывал идеи по развитию, реализовывал чужие идеи по развитию, настраивал автозадачи, рефакторил и оптимизировал код.
Каждый день — любая задача из этого списка. Сделал одну задачу — красавчик. Можно несколько.
Наблюдения вел 3 месяца. За это время сделал 30 проверок, придумал 200 идей, реализовал 80 чужих идей, выстроил автоматизированные процессы двух отделов, сделал три крутых оптимизации.
Круто, чё. Это ж «между делом». Всем рекомендую.
→ habr.com/ru/post/344934
Словом «Scrum» называются, как минимум, две сущности: философия и фреймворк.
Философия, или подход к работе, описан в книге Джеффа Сазерленда.
Фреймворк, т.е. алгоритм действий, описан в документе под названием Scrum Guide.
Философия превратилась в фреймворк, потому что авторы философии хотели заработать на ней денег (по их собственным словам).
Фреймворк сильно упрощен, по сравнению с философией. Главное — упрощена, а точнее выкинута, цель.
Цель философии: ускорение достижения результата. Причем, в разы. В книге есть примеры ускорения в 8 раз.
Цель фреймворка: чтобы у вас был Scrum. Там так и написано: делаете по инструкции — у вас Scrum, нарушаете инструкцию — у вас не Scrum.
Фреймворк не предполагает ускорения достижения результата, вообще.
Люди, преподающие или внедряющие Scrum, работают с фреймворком. Рассказывают и внедряют алгоритм, не приводящий ни к каким результатам, кроме «у нас теперь Scrum».
Суть понятна. Философию продавать очень сложно. Фреймворк — проще.
Фреймворк — это продукт. Он, как положено, прошел «упаковку». Он прост, понятен, есть поддержка и много специалистов. Ничего не напоминает?
Всё хорошо, кроме результата — его нет.
Если заказчик не знаком с философией Scrum, то внедрение фреймворка его вполне устроит.
Если заказчик знаком с философией Scrum, то от внедрения фреймворка его ждет разочарование — никакого ускорения достижения результата не будет.
Будет прикольно, модно, современно, но никакие бизнес-цели достигнуты не будут (кроме освоения бюджета на «чего-нибудь новенькое»).
Как быть? Изучать философию Scrum. Она основана на японской философии управления качеством, суть которой: измерения и бесконечные улучшения.
К сожалению, там надо много думать, экспериментировать, наблюдать и, увы, работать. Если вам это не подходит — берите фреймворк.
→ habr.com/ru/post/345540
Я попробовал, и мне жутко понравилось. Но это пофиг — главное, что понравилось читателям. Начали возвращаться те, кто давно перестал читать, заклеймив меня графоманом. И другой хороший человек посоветовал написать краткое содержание для каждой старой статьи. Я согласился и теперь, между делом, пишу эти коротышки. Назвал их шортами.
Вашему вниманию предлагаю несколько таких шортов, по нескольким публикациям. Вдруг что-то полезное для себя найдете.
Кошка сдохла, хвост облез
Совещания очень часто проходят безрезультатно. Собрались, потрепались, разошлись.
Результаты, или продукты совещания — это решения. Вот их обычно и нет. А если есть, то не всегда хорошего качества.
Если совещание ограничено по времени, и решение надо принять обязательно, то оно (решение) бывает низкого качества.
Если совещание не ограничено по времени, и длится до принятия решения, то принимается любое решение, лишь бы закончилось совещание.
Если решение придумано на совещании, то будет принято оно — просто потому, что мозг ценит то, что придумал.
Понимание низкого качества решения придет позже, но будет уже поздно.
Чтобы принять эффективное решение, лучше не участвовать в обсуждении, а молча наблюдать.
Во-первых, мозг не будет занят придумыванием ответов.
Во-вторых, не давит необходимость принять решение.
После окончания совещания можно спокойно обдумать и принять решение. Оно будет более качественным.
Ключевое: на совещании молчать и слушать. Чтобы окружающие не переживали, сказать, что это осознанная позиция.
→ habr.com/ru/post/341654
Латентные паразиты
Принципиально есть два подхода к постановке задач и контролю исполнения: паразитарный и симбиотический.
Симбиотический подход — сделать так, чтобы задача была решена.
Паразитарный подход — сделать так, чтобы задача НЕ была решена.
Симбиотический подход прямой и незамысловатый, но сложный в реализации. Поэтому встречается редко.
Задача ставится так, чтобы было понятно всё — и цели, и ресурсы, и ограничения.
Контроль осуществляется так, чтобы задача точно была решена.
Симбиотический подход — это оставлять часть ответственности (причем, бОльшую) за решение задачи на постановщике.
Паразитарный подход витиеватый и хитровыдуманный, но простой в реализации. Поэтому встречается часто.
Задача ставится так, чтобы не было понятно ничего. Чем меньше понятно, тем лучше.
Контроль, желательно, не осуществлять вообще.
Никакой ответственности на постановщике задачи нет, вся «обезьяна» пересаживается на шею исполнителя.
Цель паразитрного подхода: манипуляция, ЧСВ, самоутверждение. Поэтому часто встречается в работе наставников с начинающими сотрудниками.
Лучше, конечно, симбиотический подход.
→ habr.com/ru/post/343696
Измерения vs Иллюзии
Если оценивать процесс и результаты своей деятельности без измерений, то всё время будете ошибаться.
Оценка без цифр зависит от настроения. Плохое настроение — будет казаться, что вы плохо работаете. Хорошее настроение — наоборот.
Так можно неделю сидеть и плохо работать, а в пятницу выдать «на гора» результат, и будет казаться, что вся неделя прошла хорошо.
Принципиально, есть два типа метрик: количественные и альтернативные (более известные программистам как Булево).
«Задача выполнена в срок» — это Булево. Это то же самое, что «Деталь годная» (альтернативный признак качества, когда не могут измерить в цифрах).
«Мы работаем хорошо», «Мы выполняем план», «Я — молодец» — тоже Булево.
На оценках типа Булево процесс управления построить сложно. Рекомендуется как можно быстрее перейти к количественным метрикам.
Булево порождает бюрократию и формализм. Например, выполнения задач в срок можно добиться, увеличивая сроки, придумывая себе задачи, осуществляя ИБД.
Чтобы управлять на основе Булевых показателей, надо тратить много времени — на совещания, анализ и т.д. Потому что информации слишком мало.
Рекомендуется измерять и процесс, и результат. Тогда картина будет наиболее полной.
Для программистов рекомендуется метод «Покер планирования» из Скрама.
→ habr.com/ru/post/343910
Это Спарта
Допустим, вы — программист, и вам принесли серьезную задачу. А вы считаете, что задачу решать не надо — глупая она, вредная.
Типичное поведение в такой ситуации: вывести задачу в публичное поле. Отправить согласовывать с начальником, внутренний проект запустить, в системе зафиксировать и т.д.
На этом месте всё ломается. Человек, который принес задачу, не хочет, чтобы его считали дураком. А раз вышли в публичное поле, будет защищаться.
Человеку важно не потерять лицо, в политическом смысле. Главное в политике — никогда не признавать своих ошибок. Можно ничего не делать, но главное — не иметь признанных ошибок.
Человек приложит все силы, чтобы доказать, что программист — злодей, идиот, противник перемен. И программисту всё равно придется решить задачу.
В некоторых случаях человек устроит всё так, чтобы программист не решил задачу вообще. Тогда человек будет «белым», а программист — абсолютно «черным» (и сопротивлялся, и не справился в итоге).
Решений несколько.
Первое — стать бизнес-программистом, разобраться в смежных областях, и самому определять, что и как там надо автоматизировать.
Второе — статья Главным по изменениям. Например, директором по развитию.
Третье — не возникать, и просто делать то, что говорят.
Четвертое — Путь Спарты, быстрая отбраковка решений. Более известен, как fail fast, fail cheap (проваливайся быстро, проваливайся дешево).
Главное — не включать публичность. Сказать человеку — давай не будем тратить много времени, сделаем прототип, и посмотрим, жизнеспособно решение, или нет.
На прототип уйдет немного времени. В случае удачи оба получат свое — и решение нормальное, и политические баллы.
В случае неудачи никто не пострадает. Ну и человек будет к программисту лучше относиться.
→ habr.com/ru/post/344650
Суррогаты
Бизнес не любит 1С и ее продукты, веб-разработчиков, СМК, бухучет, экономистов, проекты развития, Scrum, ТОС, контроллинг, KPI и системы мотивации.
Бизнес любит повышение прибыльности за счет автоматизации, рост оборота от продвижения в интернете, повышение качества продукции, простую и понятную картину бизнеса в цифрах, прогнозы состояния компании, реальное повышение эффективности, ускорение выполнения проектов в 2-4 раза, кратное увеличение прибыли и снижение запасов, точную систему управления, четкую и понятную систему оценки положения дел в бизнесе, систему оценки труда, позволяющую уволить половину менеджеров.
Бизнес любит достижения бизнес-целей. Бизнес не любит суррогатов.
Суррогат — это когда просили достичь бизнес-цели, а получили проект автоматизации, сайт, кипу бумаги, штат непонятных сотрудников или нечитаемые портянки-отчеты.
Суррогат — это когда цель по дороге заменили средством достижения. А про цель дружно забыли.
Производство суррогатов зиждется на трех китах: формализм, постепенность и круговая порука.
Формализм — это перенос целей на бумагу с декомпозицией. А по сути — перевод фокуса внимания с большой цели на мелкие детали. Про цель уже никто не помнит — все обсуждают детали.
Постепенность — это низкая скорость перехода от целей к средствам. Поначалу цель еще иногда обсуждается. Но постепенно, шаг за шагом, упоминается всё реже. Пока заказчик сам про нее не забудет, потонув в деталях.
Круговая порука — в том, что все подрядчики действуют примерно одинаково. Нет ни одного автоматизатора, который реально увеличивает прибыль. Поэтому у заказчика особо и выхода-то нет.
Чего делать?
Избегать суррогатов и первого шага на пути к их созданию: формализма. Хотя бы на внутренних проектах. Ставьте цель и разговаривайте с исполнителем о ней постоянно. О масштабах, ресурсах, планах и т.д. — тоже. Но главное — о цели.
Иначе фокус внимания непременно сместится, и вы получите очередной суррогат.
→ habr.com/ru/post/344844
Джеб Кличко
Есть такой боксер — Владимир Кличко. У него есть особенность — постоянное использование джеба. Ну т.е. более постоянное, чем у других боксеров.
Джеб постоянно держит соперника в напряжении, выматывает.
Ключевые особенности джеба Кличко: простота исполнения (относительная, разумеется) и постоянство.
О том, что постоянно выполняемые, полезные, но простые действия могут принести много пользы, говорят многие авторы.
Я тоже решил попробовать. Сделал простенькую систему учета — какие джебы я сегодня сделал.
Дело было на заводе. Джебы делал в обед (я не обедаю), т.е. 1 час в день. Делал то, что другие не делают (говорят, это приводит к успеху).
Настраивал проверки самообучаемой системы, придумывал идеи по развитию, реализовывал чужие идеи по развитию, настраивал автозадачи, рефакторил и оптимизировал код.
Каждый день — любая задача из этого списка. Сделал одну задачу — красавчик. Можно несколько.
Наблюдения вел 3 месяца. За это время сделал 30 проверок, придумал 200 идей, реализовал 80 чужих идей, выстроил автоматизированные процессы двух отделов, сделал три крутых оптимизации.
Круто, чё. Это ж «между делом». Всем рекомендую.
→ habr.com/ru/post/344934
Гибкий суррогат
Словом «Scrum» называются, как минимум, две сущности: философия и фреймворк.
Философия, или подход к работе, описан в книге Джеффа Сазерленда.
Фреймворк, т.е. алгоритм действий, описан в документе под названием Scrum Guide.
Философия превратилась в фреймворк, потому что авторы философии хотели заработать на ней денег (по их собственным словам).
Фреймворк сильно упрощен, по сравнению с философией. Главное — упрощена, а точнее выкинута, цель.
Цель философии: ускорение достижения результата. Причем, в разы. В книге есть примеры ускорения в 8 раз.
Цель фреймворка: чтобы у вас был Scrum. Там так и написано: делаете по инструкции — у вас Scrum, нарушаете инструкцию — у вас не Scrum.
Фреймворк не предполагает ускорения достижения результата, вообще.
Люди, преподающие или внедряющие Scrum, работают с фреймворком. Рассказывают и внедряют алгоритм, не приводящий ни к каким результатам, кроме «у нас теперь Scrum».
Суть понятна. Философию продавать очень сложно. Фреймворк — проще.
Фреймворк — это продукт. Он, как положено, прошел «упаковку». Он прост, понятен, есть поддержка и много специалистов. Ничего не напоминает?
Всё хорошо, кроме результата — его нет.
Если заказчик не знаком с философией Scrum, то внедрение фреймворка его вполне устроит.
Если заказчик знаком с философией Scrum, то от внедрения фреймворка его ждет разочарование — никакого ускорения достижения результата не будет.
Будет прикольно, модно, современно, но никакие бизнес-цели достигнуты не будут (кроме освоения бюджета на «чего-нибудь новенькое»).
Как быть? Изучать философию Scrum. Она основана на японской философии управления качеством, суть которой: измерения и бесконечные улучшения.
К сожалению, там надо много думать, экспериментировать, наблюдать и, увы, работать. Если вам это не подходит — берите фреймворк.
→ habr.com/ru/post/345540
