Flowcon, или Флакон – методика управления, в том числе – задачами. Потоком, проектом, разработкой, рутинными функциями, регуляркой и т.д.

Многие, узнав о методике и решениях на ее основе, задают вопросы – что да как, в чем суть, на основе каких «мировых практик» сделано, какие метрики используются, кому подходит, откуда вообще взялось. Я отвечал каждому индивидуально, но решил – все, стопэ, надоело писать одно и то же по сто раз. Программист я, или кто? Повторное использование может быть не только для кода, но и для информации. Напишу один раз, постараюсь ответить в статье на все вопросы, и будь что будет.

Лучше всего, мне кажется, в виде истории изложить, потому что рождение флакона тесно связано с моей, с позволения сказать, карьерой. Так и поступлю. Погнали.

PMBOK

Первая методика управления проектами и задачами, которую я познал, называлась PMBOK. Это был далекий 2006 год.

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

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

В те времена ни клиенты, ни внедренцы не умели делать толковое ТЗ, писать функциональные требования, моделировать работу предприятия. Да и конфигурации, вроде УПП, постоянно подкидывали сюрпризы – они развивались. В результате составленный перечень работ становился неактуальным где-то через день после начала проекта.

Но мозги у программистов пытливые, и они придумали некую комбинацию PMBOK и не известного тогда никому эджайла (Agile). Назовем его «Желтый эджайл». И я тоже, вынужденно, стал его апологетом.

Желтый эджайл

Желтый эджайл основывался на этапах, созданных по PMBOK, только кардинально подменял цель каждого из них. В PMBOK цель какая? Выполнить все задачи этапа.

Желтый эджайл придумал другую цель: подписать акт. Например, есть этап – «Внедрение складского учета». На этапе проектирования и составления ТЗ в нем появляются некие работы, типа «Материальный отчет», «Обучение пользователей», «Настройка прав доступа» и т.д. – в зависимости от глубины проработки на этапе экспресс-обследования.

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

Сначала мозги, испорченные PMBOK’ом, говорили: нет! Так нельзя! Делать надо только то, что написано в ТЗ! И руководители проектов вступали в длительные негативные переговоры с клиентом. У кого-то получалось уломать заказчика на доп.работы, доп.ТЗ и так далее. У большинства – нет. Заказчик говорил: блин, ребята, я душе не знаю, что такое ТЗ, и какие доработки в вашей программе надо сделать, чтобы у меня все заработало, но если не заработает, я акт не подпишу.

Реальность, в основном, побеждала, и проект жил в двух измерениях – план и факт. План, казалось бы, можно выкинуть, но есть загвоздка – по нему составлен бюджет, который защищает перед кем-то руководитель проекта со стороны заказчика, и трогать его нельзя. А факт оставался фактом – надо сделать минимум из максимума того, что хочет заказчик, чтобы подписать акт, иначе не будет ни платежки, ни, соответственно, зарплаты.

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

CORE PM

Так, до кучи упомяну. Видя проблемы с управлением проектами у себя и коллег, я стал ковырять теорию за пределами PMBOK, и нашел в магазине книжку с незамысловатым названием «Управление проектами», за авторством четы Тейт. Они назвали свой метод CORE PM.

Суть примерно та же, что и в PMBOK. Главным названа неизменность плана. Прям отдельная большая, сложная и бюрократизированная процедура придумана, как вносить изменения в план.

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

Умные Дяди

Про то, что нет на свете Умных Дядей, я понял давно, еще в институте, когда практику проходил. Я тогда увлекался статистическими методами управления качеством продукции, и ездил на завод, где проторчал месяц, собирая данные для диплома.

Сначала целью был именно сбор данных, которые мы с преподом потом хотели покрутить в специализированном ПО (Statistica?). Вроде, мысль была построить математическую модель конвейерного производства, чтобы понять влияние разных этапов на качество конечной продукции.

Препод, перед поездкой, сунул мне какие-то книжки про карты Шухарта, статистическое управление процессами (SPC), всеобщее управление качеством (TQM). Сам он их, судя по всему, не читал – иначе не предлагал бы построить мат. модель производства. Они годились, например, для датчиков давления, где построение модели и регрессионный анализ по Дрейперу были основой калибровки, но не для автопрома.

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

А формулы были мегапростыми. Берешь сотню деталей, измеряешь, вносишь цифры в эксель, считаешь среднее, стандартное отклонение (та самая сигма), и выводишь простой и понятный показатель – индекс пригодности, или индекс воспроизводимости (если процесс стабилен). Собственно, этот показатель четко говорил, нормально все с процессом, или нет.

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

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

До меня тогда дошла ключевая мысль: Умные Дяди много знают, но ни черта не делают.

Методик полно – и по управлению качеством, и по управлению задачами/проектами, и по управлению вообще. Спроси любого эффективного менеджера – целую лекцию тебе прочитает, как и что надо делать согласно такой-то методике. А спроси мельком – делает ли он то, что в методике написано? Фиг там.

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

Русская модель управления

Поняв, что все придется постигать самому, я решил чего-нибудь еще почитать. Хотелось не новую готовую методику освоить, а понять что-нибудь более фундаментальное. На глаза попалась книга «Русская модель управления» Александра Прохорова.

Сказать, что книга гениальная – значит, ничего не сказать. Вам обязательно над ее почитать, если вы работаете в России. Там, к счастью, нет готовых рецептов, но шикарно расписаны все корневые причины того, почему у нас все так, как есть.

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

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

Вторая – русские люди лучше всего работают в т.н. кластерных ячейках, т.е. небольших командах, не контролируемых слишком плотно. Open space – это не для нас. Как вы понимаете, тот же принцип заложен в скрам.

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

Флакон после этой книги невероятно обогатился. Правда, методы решения этих «русских» проблем пришлось искать самостоятельно. Я нашел контроллинг.

Контроллинг

Контроллинг – это управление на основе цифр. Одна из любимых моих методик. Подчеркну главное: контроллинг – это не контроль. Это управление.

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

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

Цифра должна быть качественной, но такие встретишь редко. Я об этом несколько статей уже написал, повторяться не буду. Просто поверьте на слово – качественные, по критериям контроллинга, цифры встретишь очень не часто. Вероятно, потому, что никто статью в википедии про контроллинг не читал.

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

Boundary management

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

Суть безумно проста: границы. Внутри бизнес-систем, процессов, даже в одном человеке – масса границ. Физических, эмоциональных, энергетических, и т.д.

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

Короче, границы и управление ими – это мегакруто. Чтобы это понять, надо попробовать. Толковым людям, вроде вас, достаточно понять ключевой принцип, чтобы начать его применять. Остальным нужны кейсы и конкретные практики, и таких, на самом деле, множество. Только их нет в интернете, а надо придумывать самим.

Я придумал несколько, из опубликованных – Айсберг и метод плавательных дорожек.

Boundary management оказал очень сильное влияние на флакон, причем почти на все его части – на управление жизненным циклом задачи, на организацию приоритетов, на регулярный менеджмент.

Ад своими руками

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

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

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

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

Системное мышление

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

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

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

Или вы думали, что в команде координатор – начальник. Предусмотрели для него АРМ, со списком входящих задач, которые он будет распределять по исполнителям. Запускаете систему, и обнаруживаете, что ни черта он не распределяет, а только бегает по совещаниям и корпоративам. А задачи распределяет тихий, невзрачный на вид парень, сидящий в углу – скрытый лидер. А он, обидевшись на то, что его не заметили, еще и начнет саботировать внедрение вашей системы.

Это – эмерджентные свойства. Их не видно при умозрительном проектировании, они появляются при запуске системы в работу.

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

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

А если вы, например, программист, автоматизирующий управление задачами, то не просто можете, но и будете очень многое игнорировать. Так проще. Поэтому система может и будет не работать. Багов не будет, но и толку – тоже.

А мне хотелось, чтобы работало. Поэтому я добавил во флакон системное мышление – и как один из фундаментальных принципов, и как конкретные акценты и практики.

Кодекс самураев и Книга Пяти Колец

Звучит странно, но именно эти книги сделали флакон флаконом. Сейчас кратко поясню.

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

Он уходил из школы, и шел шарашиться по древней Японии, в поисках нового челленджа. Заходил в разные школы, вызывал местного мастера на поединок, и по результатам принимал решение. Если мастер оказывался слабее самурая – что ж, не судьба. Если же самурай проигрывал, то он падал на колени и просил взять его в ученики. И учился до тех пор, пока снова не превосходил мастера.

Так продолжалось несколько раз. И в какой-то определенный момент у самурая рождался собственный стиль.

Вообще, он рождался не у всех, это нормально. Некоторые так и оставались «без лица», будучи лишь мастерами нескольких известных школ (это типа MBA).

А некоторые придумывали свой стиль еще до поступления в первую школу. Например, один из национальных героев Японии Миямото Мусаси, изобретатель стиля двух мечей и автор Книги Пяти Колец. Или Масутацу Ояма, по национальности кореец, создатель школы карате Киокушинкай. И тот, и другой изобрели свой метод где-то в начале карьеры, а потом его оттачивали. И тот, и другой на своем пути встречали более сильных мастеров, и оставались у них поучиться.

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

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

Так вот, после прочтения этой книги я впервые понял, чем занимаюсь. Я, как приличный самурай, начал с той школы, что была в шаговой доступности – с PMBOK. Потом стал добавлять другие школы. Правда, я частенько совершал ошибку, неприличную для приличного самурая – не совмещал практики, а замещал одну другой, в поисках серебряной пули. Не подходит PMBOK – выкидываем, берем CORE PM, не получается – опять бросаем, кидаемся в скрам, и так далее. Поэтому тактику я сменил – стал применять новые практики в качестве эксперимента, смотреть что получится, и оставлять наиболее удачные решения во флаконе.

Бизнес-программирование

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

Так получилось, что бизнес-программирование развивалось параллельно с флаконом, и объектом улучшений становилось все, что угодно, кроме родного ИТ-отдела.

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

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

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

Скрам

Есть в этом мире два скрама – правильный, и неправильный. Правильный описан в книге Джеффа Сазерленда. Неправильный – в т.н. scrum guide, причем в авторах числится все тот же Джефф Сазерленд.

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

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

В общем, я взял книжку и сделал все так, как в ней написано. Доска, стикеры, митинги, ретроспективы и т.д. Результат оправдал все ожидания – мы ускорились вдвое, то есть стали производить в два раза больше результата за единицу времени.

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

Но лучшее оставили во флаконе. Что лучшее в скраме? Правильно, система измерения задач – покер планирования. Ничего более приличного для оценки задач программистов в нашем мире не существует.

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

Из остальных элементов скрама во флаконе остался, пожалуй, только спринт, как один из вариантов планирования. Кто работал с 1С, то знает, что спринт – это самое обычное объемно-календарное планирование, т.е. некое количество продукции, которое надо продать/купить/произвести за определенный период.

Так что, спасибо, скрам, за все, чему ты нас научил, но могилу себе ты вырыл сам, своим scrum guide. Мы взяли только лучшее.

Потоковый скрам

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

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

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

Короче, стикеры – не то. И диаграмма сгорания – не то. Скрам ведь рассчитан на реализацию проектов, а проект – это что такое? Это некая деятельность, которая когда-нибудь закончится. Она должна закончиться, в этом смысл, это цель.

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

Ответ дал господин президент России, когда рассказывал о своей работе премьер-министром в 2008-2012 годах. Он сказал: быть премьером – как стоять под водопадом бесконечных задач, проблем и целей. Работа не заканчивается никогда. Сколько не старайся, всегда будет чем заняться.

Что есть водопад? Это поток. Так и появилась идея потоков. Спасибо, Владимир Владимирович.

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

Суть проста. Задачи снабженцу всегда приходят извне – от потребностей продаж и производства. Система приоритетов у этих задач очень простая. А суть работы еще проще – от забора и до обеда.

Возникла потребность во втулках – закажи втулки. Нужны болты – ну, ты знаешь, что делать. И так далее, до бесконечности. Потому что поток.

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

Результат был ошеломляющий по качеству и скорости достижения – за месяц наполнили консигнационный склад до уровня, недостижимого ранее, за годы «обычного» управления.

Ну и тут, в какой-то момент, до меня дошло, что на внутренней автоматизации тоже нет проектов, а есть поток. Разбиение внутренней автоматизации на проекты – условность, пришедшая, как наследие большой любви 1Сников к PMBOK. Проекты нужны там, где есть деньги, сроки, бюджеты, формальности и бюрократия. Если все это есть во внутренней автоматизации, то явно надо что-то делать.

В общем, потоки и управление ими прочно вошли во флакон. Забегая вперед, скажу, что и название Flowcon образовано от словосочетания flows control (управление потоками).

Теория ограничений систем (ТОС)

Теория ограничений систем Голдратта – принцип, говорящий, что в любой системе есть ограничение, самое медленное звено, скоростью работы которого определяется общая скорость системы. Ну и куча методов на основе этого принципа разработана, и самим Голдраттом, и его последователями. Например, методика Velocity, описанная в книге «Новая цель» — в ней замешаны ТОС и Lean.

Из ТОС во флакон попал, конечно, главный принцип – понимание наличия ограничений, и средств работы с ним. Сознательно не пишу «устранения ограничений», т.к. ТОС предполагает не только устранение, но и защиту ограничения, а иногда – и искусственное их создание.

Именно ТОС заставил меня посмотреть не только на фазу исполнения задачи, но и на «обвес» — то, что происходит до и после работы непосредственного исполнителя. Не секрет, что зачастую исполнение задачи занимает 15 минут, а принятие в работу, согласование, приемка результата, в сумме – несколько дней. И все эти несколько дней заказчик, или инициатор задачи, ждет.

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

Точки зрения разные, а результат один – задача решается непозволительно долго. И согласование – лишь один из примеров. А выбор задачи программистом, когда «бюллетень» непозволительно длинный? Это ли не ограничение? А неправильный выбор исполнителя, когда задачи одного типа всегда попадают к одному исполнителю, и перед ним выстраивается супердлинная очередь?

Попали во флакон и конкретные методы из ТОС, например – использование буфера для определения момента запуска задачи в работу, если у нее есть срок исполнения. Но главное в ТОС, конечно, принцип, а не методы. Об этом писал сам Голдратт в статье «Стоя на плечах гигантов».

Стоя на плечах гигантов

Это такая знаменитая статья Голдратта, в которой он расставляет все на свои места, в том числе – своими голдраттовскими словами рассказывает, кто такие приличные самураи. Пересказывать статью не буду, она есть в открытом доступе в интернете.

Приведу лишь ключевую цитату.

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

Если своими словами, то Голдратт говорит то же, что самураи и системное мышление: не надо фантазировать, не надо кричать «скрам форева» или «ТОС — фигня», потому что вы всегда будете не правы. Берите и пробуйте, и не забывайте, что никакая методика в чистом виде вам не подойдет. Все равно придется наблюдать, думать и корректировать.

Наблюдения

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

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

Как писал на смешной картинке Максим Дорофеев, автор джедайских техник, какой смысл ждать наступления срока, чтобы сделать через *опу, если можно сразу сделать через *опу, но будет время все исправить?

Я неоднократно видел – и у себя, и у других, что выбор варианта решения задачи может занимать дни. Притом, что варианты могут быть совершенно идентичны по производительности, оптимальности и удобству пользователя. Но вот что-то не дает никак решиться, и все тут. Работы – на 15 минут, а раздумий – будто ракету строишь.

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

Беспощадная автоматизация

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

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

Переложение на новую систему

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

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

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

Вызов стал еще интереснее. Одно дело – создавать систему самому, с нуля, и совсем другое – приспособить существующую, чтобы она отвечала требованиям методики. При том, что менять в ней ничего нельзя – доступен лишь типовой интерфейс, и API.

Вот с API я и начал. Оно не сказать, что прям шикарное, но данных дает вполне достаточно. Первой проблемой оказалась невозможность указания оценки задачи, в виде числа. Пришлось выкручиваться через метки (labels) – они строкового типа, но можно превращать в число внешним скриптом. Я этот скрипт написал, и несколько месяцев им пользовался – он рисовал график эффективности.

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

В общем, ветка оказалась тупиковой. Я пошарился по другим онлайн-системам управления задачами – проблемы аналогичные. Везде есть возможность ввода и хранения данных, но очень мало инструментов настройки – а именно настройка превращает данные в систему управления. Везде есть API, и через него можно построить свою систему, но тогда вопрос – а зачем их система? Только, как источник данных?

Эта дилемма сидела в моей голове несколько месяцев. Делать или нет? Приспособить методику к GitHub, изготовив свою нашлепку? Или к другой системе? В чистом виде ни одна не подходит, но и приспособить ни одну нельзя, за разумное время. Да и пользоваться внешними скриптами поднадоело уже.

Но, несмотря на дилемму, опыт был удачным. Флакон вполне себе отлично работал, хоть и на стоявшей нараскоряку системе, и давал ускорение работы – сначала в 4 раза, потом в 6, доходило до 10. Понятно, что коэффициент зависит от точки отсчета, но я на эту тему давно перестал переживать – мне флакон уже все доказал.

Переложение еще на одну новую систему

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

Тут, как раз, народ собирался на очередную 1Сную конференцию, и я решил там поучаствовать. Взял типовой, пустой 1С: Документооборот, и принялся в нем настраивать свою методику – флакон. Честь и хвала 1С: Документообороту – на настройку ушло несколько часов, и получилась вполне приличная система управления задачами, в высокой степени соответствующая флакону.

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

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

Своя система

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

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

Что интересно, разработка программы сразу стала давать обратную связь методике. Некоторые вещи пришлось из флакона выкинуть, некоторые – добавить, что-то – изменить. Мы сами, разумеется, быстренько пересели с GitHub на Flowcon.

И снова потоки

Раньше я никогда не руководил компанией. Собственно, я и сейчас не сказать, что руковожу – нас тут двое, и права с обязанностями поделены примерно пополам. Но заниматься приходится всеми вопросами жизнедеятельности компании, а не только разработкой или внедрением.

У нас есть разработка ПО, сервисов, доработка старых продуктов, внедрения у новых клиентов, чистые продажи без услуг, поддержка старых клиентов, маркетинг, переговоры, выставки с семинарами, бытовые вопросы, вроде денег и т.п. Короче, мы – компания в миниатюре.

Такое положение дел заставило пересмотреть флакон, внести в него две новые сущности – потоки и баланс.

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

Хочется засесть, например, за разработку нового продукта, и не вылезать неделю. Что при этом произойдет? Денег не будет, потому что новый продукт черт знает когда начнет продаваться. Надо переключаться на работу с клиентами.

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

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

Есть потоки, которые можно измерять и планировать. Например, 100 часов в месяц – на услуги, 300 баллов – на разработку новых продуктов, и в промежутках – 4 статьи. У каждого потока своя единица и способ измерения, и своя цель. А флакон должен эти потоки балансировать, обеспечивая равномерное развитие компании.

Разумеется, потоков не три, а больше – и у нас, и у вас. А балансировать надо всем, кто хочет устойчивого развития, построенного на стратегии, а не на текущем контексте и тушении пожаров.

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

Управление разработкой

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

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

Пришлось флакон корректировать – вводить понятие релизов, и перестраивать систему расстановки приоритетов с их учетом. Релиз ведь – это не проект, и не задача, а некое вместилище других задач, которые надо сделать, чтобы релиз состоялся. А релиз, особенно первый – это выход на рынок. Пока он не случится, продукт никто не увидит и, соответственно, не будет ни обратной связи, ни денег.

Кого еще забыл?

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

Есть еще куча методик и практик, которые повлияли на флакон, но я не буду их перечислять. Возможно, когда-нибудь, сделаю что-то вроде глоссария, или списка литературы – для тех, кто сильно уважает всякие научные подходы, индексы цитируемости и «опору на всемирно известные методики».

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

Что в итоге?

В итоге мы имеем флакон – гремучую смесь лучших практик по управлению, которая повышает эффективность. И существует ровно для того, чтобы повышать эффективность.

Что важно лично для меня – это именно смесь, набор, а не последовательность. Можно применить все методы, можно – только один, или половину, на ваш выбор. Любой метод, сам по себе, дает прирост эффективности. Один больше, другой меньше.

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

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

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

Так что, все будет хорошо.