Недавно, совершенно случайно, с подачи одного хорошего человека, родилась идея — к каждой статье прикладывать краткое содержание. Не аннотацию, не завлекаловку, а именно краткое содержание. Такое, чтобы можно было статью не читать вообще.
Я попробовал, и мне жутко понравилось. Но главное, что понравилось читателям. Начали возвращаться те, кто давно перестал читать, заклеймив меня графоманом. И другой хороший человек посоветовал написать краткое содержание для каждой старой статьи. Я согласился и теперь, между делом, пишу эти коротышки. Назвал их шортами.
Вашему вниманию предлагаю несколько таких шортов, по нескольким публикациям. Вдруг что-то полезное для себя найдете.
Кошка сдохла, хвост облез
Совещания очень часто проходят безрезультатно. Собрались, потрепались, разошлись.
Результаты, или продукты совещания — это решения. Вот их обычно и нет. А если есть, то не всегда хорошего качества.
Если совещание ограничено по времени, и решение надо принять обязательно, то оно (решение) бывает низкого качества.
Если совещание не ограничено по времени, и длится до принятия решения, то принимается любое решение, лишь бы закончилось совещание.
Если решение придумано на совещании, то будет принято оно — просто потому, что мозг ценит то, что придумал.
Понимание низкого качества решения придет позже, но будет уже поздно.
Чтобы принять эффективное решение, лучше не участвовать в обсуждении, а молча наблюдать.
Во-первых, мозг не будет занят придумыванием ответов.
Во-вторых, не давит необходимость принять решение.
После окончания совещания можно спокойно обдумать и принять решение. Оно будет более качественным.
Ключевое: на совещании молчать и слушать. Чтобы окружающие не переживали, сказать, что это осознанная позиция.
Латентные паразиты
Принципиально есть два подхода к постановке задач и контролю исполнения: паразитарный и симбиотический.
Симбиотический подход — сделать так, чтобы задача была решена.
Паразитарный подход — сделать так, чтобы задача НЕ была решена.
Симбиотический подход прямой и незамысловатый, но сложный в реализации. Поэтому встречается редко.
Задача ставится так, чтобы было понятно всё — и цели, и ресурсы, и ограничения.
Контроль осуществляется так, чтобы задача точно была решена.
Симбиотический подход — это оставлять часть ответственности (причем, бОльшую) за решение задачи на постановщике.
Паразитарный подход витиеватый и хитровыдуманный, но простой в реализации. Поэтому встречается часто.
Задача ставится так, чтобы не было понятно ничего. Чем меньше понятно, тем лучше.
Контроль, желательно, не осуществлять вообще.
Никакой ответственности на постановщике задачи нет, вся «обезьяна» пересаживается на шею исполнителя.
Цель паразитного подхода: манипуляция, ЧСВ, самоутверждение. Поэтому часто встречается в работе наставников с начинающими сотрудниками.
Лучше, конечно, симбиотический подход.
Измерения vs Иллюзии
Если оценивать процесс и результаты своей деятельности без измерений, то всё время будете ошибаться.
Оценка без цифр зависит от настроения. Плохое настроение — будет казаться, что вы плохо работаете. Хорошее настроение — наоборот.
Так можно неделю сидеть и плохо работать, а в пятницу выдать «на гора» результат, и будет казаться, что вся неделя прошла хорошо.
Принципиально, есть два типа метрик: количественные и альтернативные (более известные программистам как Булево).
«Задача выполнена в срок» — это Булево. Это то же самое, что «Деталь годная» (альтернативный признак качества, когда не могут измерить в цифрах).
«Мы работаем хорошо», «Мы выполняем план», «Я — молодец» — тоже Булево.
На оценках типа Булево процесс управления построить сложно. Рекомендуется как можно быстрее перейти к количественным метрикам.
Булево порождает бюрократию и формализм. Например, выполнения задач в срок можно добиться, увеличивая сроки, придумывая себе задачи, осуществляя ИБД.
Чтобы управлять на основе Булевых показателей, надо тратить много времени — на совещания, анализ и т.д. Потому что информации слишком мало.
Рекомендуется измерять и процесс, и результат. Тогда картина будет наиболее полной.
Для программистов рекомендуется метод «Покер планирования» из Скрама.
Это Спарта
Допустим, вы — программист, и вам принесли серьезную задачу. А вы считаете, что задачу решать не надо — глупая она, вредная.
Типичное поведение в такой ситуации: вывести задачу в публичное поле. Отправить согласовывать с начальником, внутренний проект запустить, в системе зафиксировать и т.д.
На этом месте всё ломается. Человек, который принес задачу, не хочет, чтобы его считали дураком. А раз вышли в публичное поле, будет защищаться.
Человеку важно не потерять лицо, в политическом смысле. Главное в политике — никогда не признавать своих ошибок. Можно ничего не делать, но главное — не иметь признанных ошибок.
Человек приложит все силы, чтобы доказать, что программист — злодей, идиот, противник перемен. И программисту всё равно придется решить задачу.
В некоторых случаях человек устроит всё так, чтобы программист не решил задачу вообще. Тогда человек будет «белым», а программист — абсолютно «черным» (и сопротивлялся, и не справился в итоге).
Решений несколько.
Первое — стать бизнес-программистом, разобраться в смежных областях, и самому определять, что и как там надо автоматизировать.
Второе — статья Главным по изменениям. Например, директором по развитию.
Третье — не возникать, и просто делать то, что говорят.
Четвертое — Путь Спарты, быстрая отбраковка решений. Более известен, как fail fast, fail cheap (проваливайся быстро, проваливайся дешево).
Главное — не включать публичность. Сказать человеку — давай не будем тратить много времени, сделаем прототип, и посмотрим, жизнеспособно решение, или нет.
На прототип уйдет немного времени. В случае удачи оба получат свое — и решение нормальное, и политические баллы.
В случае неудачи никто не пострадает. Ну и человек будет к программисту лучше относиться.
Суррогаты
Бизнес не любит 1С и ее продукты, веб-разработчиков, СМК, бухучет, экономистов, проекты развития, Scrum, ТОС, контроллинг, KPI и системы мотивации.
Бизнес любит повышение прибыльности за счет автоматизации, рост оборота от продвижения в интернете, повышение качества продукции, простую и понятную картину бизнеса в цифрах, прогнозы состояния компании, реальное повышение эффективности, ускорение выполнения проектов в 2-4 раза, кратное увеличение прибыли и снижение запасов, точную систему управления, четкую и понятную систему оценки положения дел в бизнесе, систему оценки труда, позволяющую уволить половину менеджеров.
Бизнес любит достижения бизнес-целей. Бизнес не любит суррогатов.
Суррогат — это когда просили достичь бизнес-цели, а получили проект автоматизации, сайт, кипу бумаги, штат непонятных сотрудников или нечитаемые портянки-отчеты.
Суррогат — это когда цель по дороге заменили средством достижения. А про цель дружно забыли.
Производство суррогатов зиждется на трех китах: формализм, постепенность и круговая порука.
Формализм — это перенос целей на бумагу с декомпозицией. А по сути — перевод фокуса внимания с большой цели на мелкие детали. Про цель уже никто не помнит — все обсуждают детали.
Постепенность — это низкая скорость перехода от целей к средствам. Поначалу цель еще иногда обсуждается. Но постепенно, шаг за шагом, упоминается всё реже. Пока заказчик сам про нее не забудет, потонув в деталях.
Круговая порука — в том, что все подрядчики действуют примерно одинаково. Нет ни одного автоматизатора, который реально увеличивает прибыль. Поэтому у заказчика особо и выхода-то нет.
Чего делать?
Избегать суррогатов и первого шага на пути к их созданию: формализма. Хотя бы на внутренних проектах. Ставьте цель и разговаривайте с исполнителем о ней постоянно. О масштабах, ресурсах, планах и т.д. — тоже. Но главное — о цели.
Иначе фокус внимания непременно сместится, и вы получите очередной суррогат.
Джеб Кличко
Есть такой боксер — Владимир Кличко. У него есть особенность — постоянное использование джеба. Ну т.е. более постоянное, чем у других боксеров.
Джеб постоянно держит соперника в напряжении, выматывает.
Ключевые особенности джеба Кличко: простота исполнения (относительная, разумеется) и постоянство.
О том, что постоянно выполняемые, полезные, но простые действия могут принести много пользы, говорят многие авторы.
Я тоже решил попробовать. Сделал простенькую систему учета — какие джебы я сегодня сделал.
Дело было на заводе. Джебы делал в обед (я не обедаю), т.е. 1 час в день. Делал то, что другие не делают (говорят, это приводит к успеху).
Настраивал проверки самообучаемой системы, придумывал идеи по развитию, реализовывал чужие идеи по развитию, настраивал автозадачи, рефакторил и оптимизировал код.
Каждый день — любая задача из этого списка. Сделал одну задачу — красавчик. Можно несколько.
Наблюдения вел 3 месяца. За это время сделал 30 проверок, придумал 200 идей, реализовал 80 чужих идей, выстроил автоматизированные процессы двух отделов, сделал три крутых оптимизации.
Круто, чё. Это ж «между делом». Всем рекомендую.
Гибкий суррогат
Словом «Scrum» называются, как минимум, две сущности: философия и фреймворк.
Философия, или подход к работе, описан в книге Джеффа Сазерленда.
Фреймворк, т.е. алгоритм действий, описан в документе под названием Scrum Guide.
Философия превратилась в фреймворк, потому что авторы философии хотели заработать на ней денег (по их собственным словам).
Фреймворк сильно упрощен, по сравнению с философией. Главное — упрощена, а точнее выкинута, цель.
Цель философии: ускорение достижения результата. Причем, в разы. В книге есть примеры ускорения в 8 раз.
Цель фреймворка: чтобы у вас был Scrum. Там так и написано: делаете по инструкции — у вас Scrum, нарушаете инструкцию — у вас не Scrum.
Фреймворк не предполагает ускорения достижения результата, вообще.
Люди, преподающие или внедряющие Scrum, работают с фреймворком. Рассказывают и внедряют алгоритм, не приводящий ни к каким результатам, кроме «у нас теперь Scrum».
Суть понятна. Философию продавать очень сложно. Фреймворк — проще.
Фреймворк — это продукт. Он, как положено, прошел «упаковку». Он прост, понятен, есть поддержка и много специалистов. Ничего не напоминает?
Всё хорошо, кроме результата — его нет.
Если заказчик не знаком с философией Scrum, то внедрение фреймворка его вполне устроит.
Если заказчик знаком с философией Scrum, то от внедрения фреймворка его ждет разочарование — никакого ускорения достижения результата не будет.
Будет прикольно, модно, современно, но никакие бизнес-цели достигнуты не будут (кроме освоения бюджета на «чего-нибудь новенькое»).
Как быть? Изучать философию Scrum. Она основана на японской философии управления качеством, суть которой: измерения и бесконечные улучшения.
К сожалению, там надо много думать, экспериментировать, наблюдать и, увы, работать. Если вам это не подходит — берите фреймворк.
Шоты Белокаменцева ))
(0) Хорошее название 🙂
Все новое — это хорошо забытое старое. Встречал такую выжимку у Жюля Верна и Петра Успенского. Отлично!
Теперь Вас будут назыать Графоман Графоманович )
(1) шикарно 🙂
новое поколение выросло, статью теперь не будут читать если есть шорт
Кошка сдохла, хвост облез
Никогда ни с чем подобным не приходилось сталкиваться.
Собрания — они для нахватов предназначены. Решения давно уже приняты. либо авторитарным руководителем, либо келейно интересанты между собой договорились и теперь протаскивают это через совещание. В любом случае, все закончится тем, что будут назначены исполнители, сроки, бюджеты, что называется — кого поймают, того и нахватят.
Если задача вас касается, и перед собранием никто из интересантов это с вами не обсуждал, то таких козлов нужно наказывать, чтобы впредь неповадно было. Объяснить, что не готов к такому, нужно провести предварительную работу, и предъявить почему тебя до совещания не проинформировали о необходимости подготовиться к собранию по такой-то проблеме. И далее, технично саботировать эту тему. В следующий раз интересанты заранее к вам прибегут и будут договариваться.
В идеале — всем участникам совещания должны были прийти письма с повесткой собрания или на прошлом собрании должны быть обозначены темы этого собрания.
Нахваты — это зло неизбежное и тут самая на мой взгляд правильная стратегия — набрать себе побольше интересных нахватов, проявляя при этом инициативу, чтобы была отмазка от нахватов унылых и горбатых.
А Комиксы уже рисуют? ))
Когда ждать? ))
чето вспомнилось 🙂
Одинаковая версия 1с у всех устраняет автоматизацию как фактор конкурентного преимущества. Если все работают с одним набором инструментов и по одинаковой методике бест практис то выигрывает конкурентную борьбу тот у кого круче все остальное (например качество готовой продукции, услуг или товаров).
Если автоматизация не даёт никаких преимуществ — логично что она невыгодна. Такой парадокс..
(11) В ряде случаев автоматизация — это просто цена входного билета на рынок.
Была про это замечательная книжка 2004 года, автор Николас Карр у нас она назвалась «Блеск и нищета информационных технологий. Почему ИТ не являются конкурентным преимуществом», в оргинале — «Does IT Matter?» . Книжка актуальности не потеряла, в интернетах есть, для нашего 1с-ного бизнеса что называется «must read». Кто не читал, почитайте, рекомендую.
Насчёт входного билета — это не про 1с.
Билеты здесь.
(11) Наличие автоматизации еще долго будет конкурентоспособным.
— Виды законченного внедрения :
1) с подписанными актами выполненных работ
2) с рабочим инструментарием и качественной архитектурой
И хорошо если количество вторых будет хотя-бы 30%, качество автоматизации еще долго будет не на высоте и соответственно в цене, т.к. при скачке в квалификации специалисты идут выше зачастую не развивая того окружения где выросли из-за низкого уровня оплаты.
Большинство внедрений на бумаге, по факту разбирая текущий функционал чаще приходится видеть мертвые продукты выдающие демо цифры, а не реальную картину.
Хорошая идея с мини-обзором статей. Жду такой же гайд по остальным!!!
Офигеть!
Да это же Белокаменцев здорового человека!
Это не короткие версии статей, это правильные версии статей 🙂
Хорошо, что не стрингами назвал)