Где мы взяли флакон?

Публикация № 971984

Управление - Управление бизнес-процессами (BPM)

38
История появления и развития методики

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 раза. Наверное, только ленивый еще не посмотрел видео моих докладов на эту тему — https://www.youtube.com/watch?v=xeQe-TemEfI и https://www.youtube.com/watch?v=luWaeWaV8c8.

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

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


После того опыта я перешел в чисто софтверную компанию, и, естественно, продолжил практику применения флакона. Но столкнулся с интересным вызовом – у меня ведь не было с собой системы управления задачами, на которой я получил ускорение в 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 статьи. У каждого потока своя единица и способ измерения, и своя цель. А флакон должен эти потоки балансировать, обеспечивая равномерное развитие компании.

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

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

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


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

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

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

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


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

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

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

Что в итоге?


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

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

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

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

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

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

38

Специальные предложения

Комментарии
Избранное Подписка Сортировка: Древо
1. lunjio 62 26.12.18 20:06 Сейчас в теме
Согласен с автором в части наблюдений, вот почему не получается просто взять написать и забыть ? нужно поискать подвох, подумать про производительность. Так же бывает и обратное, сделал за 15 минут, а потом мозг собирает картинку и ты понимаешь, что это не учел и то не учел и 1 строчка кода обрастает условиями и т.п.
Про русских людей - ну не надо так слишком уж прям, много русских людей очень ценные специалисты как на западе так и на родине, возможно имеется ввиду средний класс, а не высококвалифицированные специалисты ?
В целом много полезного, но не буду все критично принимать. В копилку однозначно.
2. swimdog 678 27.12.18 00:02 Сейчас в теме
А абзацами с заголовком читать намного легче. В заголовке суть, в абзаце детали. Даже такая длинная статья была прочитана за 2 подхода.
3. v3rter 27.12.18 13:46 Сейчас в теме
Если методика флакона подошла к 1С Документообороту, то должна подходить и к CRM-системам: Битриксу24, Амо и т.п. Пробовали что-нибудь в этом направлении?
4. 1c-intelligence 8624 27.12.18 13:48 Сейчас в теме
(3) она подошла к ДО, потому что его дорабатывать можно - например, свойства добавлять, внешние отчеты и обработки подключать.
5. v3rter 27.12.18 16:45 Сейчас в теме
(4) Думаю, пользователям CRM-систем Ваша методика будет не менее интересна, тем более, что у многих CRM-систем есть функции постановки задач с ответственными, исполнителями и сроками, чаты и оповещения, роботы, возможность написания своих приложений, API, WebHook-и (выполнение действий путем обращения к URL) и другие способы интеграции с чем угодно.
6. FB_1811930315551820 02.01.19 10:57 Сейчас в теме
Так а где, собственно, сам Флакон?? Или эта статья - зондирование рынка?
Оставьте свое сообщение

См. также

Незакрытый проект на 1000 часов 62

Статья no Нет файла Россия Бесплатно (free) Управление проектом

История о незакрытом проекте, о бессонных ночах, о попытках его выгрести, о бесплатной работе, о вселенской боли.

19.09.2019    6906    ogroup    153       

Стратегия выживания в корпоративных войнах 47

Статья no Нет файла Бесплатно (free) Управление проектом

Айтишникам сложно строить карьеру управленца. И все потому, что в их «техническое ДНК» не заложено умение справляться с окружающими их интригами. Однако, поскольку это навык, это можно исправить, считает ИТ-директор в ПАО «Светлана». На конференции Infostart Event 2018 он поделился с коллегами, что и как надо делать, чтобы не погрязнуть в корпоративных интригах и сделать так, чтобы они не мешали выполнению основной работы.

16.09.2019    4077    GSoft    14       

Мастер-класс СППР 39

Статья Программист Руководитель проекта Нет файла Бесплатно (free) Управление проектом СППР

Сергей Наумов, в прошлом разработчик подсистемы бюджетирования в конфигурации «1С:ERP», на мастер-классе конференции INFOSTART EVENT 2018 EDUCATION поделился опытом управления проектами с помощью «1С:Системы проектирования прикладных решений» и показал, как использовать эту программу в работе над разными задачами: для сбора, классификации и хранения требований; для управления разработчиками и консультантами; в качестве системы документирования; в качестве баг-трекера на этапе опытно-промышленной эксплуатации.

30.08.2019    3261    SergeyN    4       

Как заработать миллион или История успешного сотрудничества 45

Статья Программист Нет файла Бесплатно (free) Управление проектом

Многие мечтают один раз что-то создать, а потом жить на заработанные деньги до конца своих дней. Но миллионерами становятся не все, их единицы. Среди них – разработчик Андрей Карпов. Человек, который сумел за полтора года заработать 2 миллиона рублей чистой прибыли, поделился с гостями конференции Infostart своими секретами.

05.08.2019    4065    karpik666    77       

Бизнес-аналитика с помощью Power BI 65

Статья Руководитель проекта Нет файла Бесплатно (free) Управление проектом

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

11.07.2019    6322    pbazeliuk    18       

Управление проектами по автоматизации бюджетирования 35

Статья Бизнес-аналитик Руководитель проекта Нет файла УУ Финансовый учет и бюджетирование (FRP) Бесплатно (free) Управление проектом

Автоматизация бюджетирования позволяет максимально эффективно планировать ресурсы предприятия и управлять масштабированием компании. Как учесть особенности бюджетирования, встроить его в процессы стратегического планирования, чтобы получить гибкий инструмент управления и аналитики, рассказал Сергей Наумов на конференции INFOSTART EVENT 2018 EDUCATION.

28.06.2019    3188    SergeyN    1       

Риск - благородное дело!.. Часть первая 31

Статья Бизнес-аналитик Руководитель проекта Нет файла Бесплатно (free) Управление проектом

Несколько рекомендаций по управлению рисками в ИТ-проектах.

18.06.2019    3815    MariaTemchina    8       

Мы в ответе за то, чего вовремя не послали. Матрица ответственности в проектах внедрения 31

Статья Бизнес-аналитик Руководитель проекта Нет файла Бесплатно (free) Управление проектом

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

31.05.2019    4122    MariaTemchina    23       

Устав писать Устав 31

Статья Бизнес-аналитик Руководитель проекта Нет файла Бесплатно (free) Управление проектом

Ответы на вопросы про то, нужен ли Устав для проектов автоматизации, и если нужен, то зачем?

06.05.2019    4029    MariaTemchina    8       

Путь джедая в управлении проектами 1С: умение быть, а не казаться 36

Статья Бизнес-аналитик Руководитель проекта Нет файла Бесплатно (free) Управление проектом

Чем руководитель проекта “на бумаге” отличается от “настоящего” руководителя проекта, умеющего направлять команду и выдавать ценный результат?

15.04.2019    6751    MariaTemchina    15       

Управление ИТ-проектами, базовый курс, 3 поток. Онлайн-курс с 15 мая по 1 июля 2019 16

Курс Бизнес-аналитик Руководитель проекта Нет файла Бесплатно (free) Управление проектом

Отличительная черта курса - органичное сочетание трех вещей: - Теория проектного управления (PMI®+Agile Alliance+Российские ГОСТ+Методологии от 1С)  - Опыт внедрения продуктов 1С (опыт франчайзи и успешных компаний + тренды Infostart Event и Agile Days) - Разбор реальных проблем и рекомендации экспертов по проектам слушателей Мы будем фиксироваться на тех инструментах, которые реально оказываются полезными в практике  руководителей проектов внедрения. 

04.04.2019    9235    infostart    18       

Уволен через автоматизацию 46

Статья no Нет файла Бесплатно (free) Управление бизнес-процессами (BPM)

Кейс бизнес-программирования

07.03.2019    7403    1c-intelligence    47       

20 мыслей об ИТ-проектах. Мысль №2. "С какой стороны подойти к новому проекту?" 38

Статья Руководитель проекта Нет файла Бесплатно (free) Управление проектом

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

13.02.2019    4410    chavalah    22       

Стыд и скрам - Чему нас учит Scream Guide 29

Статья Бизнес-аналитик Руководитель проекта Нет файла Бесплатно (free) Управление проектом

Название "Scream Guide" можно вольно перевести на русский как “Вопль ужаса от того, как Scrum применяют на практике”

12.02.2019    6076    MariaTemchina    20       

Бизнес, не горюй 33

Статья no Нет файла Бесплатно (free) Управление проектом

Про цели автоматизации.

04.02.2019    5762    1c-intelligence    64       

Ошибки управленцев: как топ-менеджеров убивает перфекционизм 5

Статья no Нет файла Бесплатно (free) Управление проектом

В преддверии онлайн-конференции «Гнев и слезы руководителя» мы решили заранее познакомить нашу аудиторию со спикерами, причем сделать это через видео-истории. Начнем с видео-приглашения от Миланы Джиджоевой и ее виденья диджитализации рекрутинга в России.

24.01.2019    6127    user809424    11       

Что немцу хорошо, то русскому... Как минимум, небезынтересно. Продолжаем тему Канбан 31

Статья Бизнес-аналитик Руководитель проекта Нет файла Бесплатно (free) Управление проектом

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

14.01.2019    6593    MariaTemchina    13       

20 мыслей об ИТ-проектах. Мысль №1. "О незаменимых людях" 62

Статья no Нет файла Бесплатно (free) Управление проектом

Этой статьей начинается цикл из 20-ти обещанных мыслей об ИТ-проектах. Надеюсь, что по прочтении кто-то посмотрит на проблему незаменимых людей с другой стороны.

10.01.2019    8955    chavalah    123       

Вы как хотите, а я сделал 54

Статья no Нет файла v8::Бизнес-процессы 1cv8.cf Бесплатно (free) Управление проектом

Хвастаюсь системой управления задачами

28.12.2018    8498    1c-intelligence    18       

Озарение после прочтения макулатуры по проектному управлению 42

Статья Бизнес-аналитик Руководитель проекта Нет файла Бесплатно (free) Управление проектом

Открываю этой публикацией мини-рубрику "Письма в редакцию". По мотивам очередной статьи на Инфостарте пришло мне письмо на корпоративную почту. Прямо-таки, крик души. С разрешения автора, решила опубликовать публичный ответ. Ибо согласна с автором письма, пишущим: "Я уверен, что не я один такой убогий, кто задается подобного рода "идиотскими" вопросами, но при этом почему-то все молчат, видимо, pmbok с agile-ом поистине творят чудеса молчания..."

19.12.2018    6463    MariaTemchina    24       

20 мыслей об ИТ-проектах, или 20 лет спустя. 53

Статья no Нет файла Бесплатно (free) Управление проектом

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

09.12.2018    5932    chavalah    119       

Памятка руководителя: не играйте с деньгами 83

Статья Пользователь Руководитель проекта Нет файла Бесплатно (free) Управление проектом Личная эффективность Управление персоналом (HRM)

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

05.12.2018    13218    andironenko    128       

Шаг назад и ... шаг назад (классификация внутренних проектов) 34

Статья Пользователь Руководитель проекта Нет файла Бесплатно (free) Управление проектом

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

03.12.2018    5512    capitan    26       

Белая и пушистая рецензия на Чёрную книгу Скрам 31

Статья Бизнес-аналитик Пользователь Руководитель проекта Нет файла Бесплатно (free) Управление проектом

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

26.11.2018    6678    MariaTemchina    40       

Памятка руководителя: Будьте оптимистичным или на крайний случай злым 46

Статья no Нет файла Бесплатно (free) Блоги Управление проектом

Следующая статья из цикла Управление персоналом - в этот раз предлагаю обсудить вопросы психологии управления и подчинения. Для тех, кто начинает читать этот цикл с этой статьи, вот ссылка на прошлый материал https://infostart.ru/public/937923/, в конце статьи будут ссылки на все статьи из серии «Памятка руководителя» - читатели просили. Итак, продолжаем работать с персоналом.

22.11.2018    8899    andironenko    43       

Создание концепции проекта (project scope statement). Курс по управлению проектами, часть 8 30

Статья Системный администратор Бизнес-аналитик Пользователь Руководитель проекта Нет файла Бесплатно (free) Управление проектом

Что такое концепция проекта? Это понятие, близкое по смыслу к техническому заданию (ТЗ). Одно из определений концепции - детальное, целостное описание работ в удобной для команды форме.

19.11.2018    4938    Selikhovkin    1       

Роевой интеллект (Swarm intelligence) как метод управления проектами (анти-утопия) 35

Статья no Нет файла Бесплатно (free) Управление проектом

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

19.11.2018    6270    capitan    41       

Почему внедрение ERP-системы не приносит пользы бизнесу? 87

Статья Бизнес-аналитик Пользователь Руководитель проекта Нет файла Бесплатно (free) Интеграция Управление проектом

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

15.11.2018    15671    rossoxa    62       

Думать некогда, трясти надо - или что такое ретроспектива в Agile 30

Статья Бизнес-аналитик Пользователь Руководитель проекта Нет файла Бесплатно (free) Управление проектом

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

13.11.2018    7272    MariaTemchina    16       

Памятка руководителя: В одиночку здесь не выжить 43

Статья Пользователь Руководитель проекта Нет файла Бесплатно (free) Управление проектом Личная эффективность

Продолжаю цикл материалов, в котором рассказываю о своем опыте работы в качестве директора по ИТ. Этот материал будет посвящен теме управления персоналом.

07.11.2018    9245    andironenko    62       

Приоритизировали, приоритизировали, да не выприоритизировали... 28

Статья Бизнес-аналитик Пользователь Руководитель проекта Нет файла Бесплатно (free) Управление проектом

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

30.10.2018    6099    MariaTemchina    47       

Памятка руководителя: Уволь HRа и найди себе хороших сотрудников 67

Статья Руководитель проекта Нет файла Управление персоналом (HRM) Бесплатно (free) Управление проектом

Продолжаю цикл «Памятка руководителя». Эта статья будет на тему поиска новых сотрудников и одной грубой ошибки при проведении собеседования.

29.10.2018    8897    andironenko    35       

Опыт внедрения ESB (интеграционной шины) в ПАО "Газпром нефть" 34

Статья no Нет файла Бесплатно (free) Управление проектом

Харитонов Михаил описывает проект по внедрению интеграционной сервисной шины предприятия (ESB) «2iS:Интеграция» на платформе “1С:Предприятие 8” в компании ПАО «Газпром нефть». Проект уникален тем, что это – первое решение, использующее отечественное ПО в качестве полноценной интеграционной шины для столь крупного заказчика с обширным ИТ-ландшафтом. В статье подробно рассмотрена архитектура решения, способы тестирования и масштабирования.

17.10.2018    7340    Mick2iS    8       

#БезОценок, или Как перестать беспокоиться об оценке проекта, всегда успевать в срок и укладываться в бюджет 32

Статья Пользователь Руководитель проекта Нет файла Бесплатно (free) Управление проектом

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

11.10.2018    5228    AlexWhite    7       

Построение высокоэффективной Agile-команды 34

Статья no Нет файла Бесплатно (free) Управление проектом

Меня зовут Асхат Уразбаев, я из компании ScrumTrek. Наша компания помогает внедрять Agile, Scrum, Kanban – гибкие методологии и гибкие подходы. К миру 1С я совсем не принадлежу, но в прошлом я, тем не менее, программист – занимался разработкой на самых разных языках программирования. Помимо основной деятельности у меня было несколько технологических стартапов, в которые я был так или иначе вовлечен. И сегодня мы поговорим о том, как сделать так, чтобы команда была крутой и эффективной.

08.10.2018    5209    askhatu    15       

История одного провала внедрения 1С:ERP 2 по классической технологии. С последующим спасением по Scrum 106

Статья no Нет файла Бесплатно (free) Управление проектом

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

01.10.2018    13337    glebushka    41       

Контракты Agile: как заключать договора в условиях расползания содержания 41

Статья Системный администратор Пользователь Руководитель проекта Нет файла Бесплатно (free) Управление проектом

В большинстве проектов, реализуемых при помощи гибких методологий, точное содержание продукта невозможно выяснить на этапе инициации. Отсюда и возникает крик души руководителей проектов – «Как можно заключить контракт, не понимая точный бюджет проекта?» В статье я попробую рассмотреть этот вопрос с двух сторон: рекомендации от идеологов Agile и опыт реальных практиков. 

25.09.2018    6815    MariaTemchina    10       

Как из разработчика сделать руководителя, даже если он этого не хочет? 70

Статья no Нет файла Бесплатно (free) Управление проектом

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

06.09.2018    8917    galina.petuhova_2015    40       

Что такое Agile mindset или, говоря по-русски, пронырливый образ мысли 47

Статья Системный администратор Пользователь Руководитель проекта Нет файла Бесплатно (free) Управление проектом

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

04.09.2018    10464    MariaTemchina    57       

Как собрать исчерпывающие бизнес-функциональные требования в начале проекта внедрения? 57

Статья Системный администратор Пользователь Руководитель проекта Нет файла Бесплатно (free) Управление проектом

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

29.08.2018    9564    MariaTemchina    28       

Три фундаментальных принципа проектного управления. Курс по управлению проектами, часть 2 29

Статья Пользователь Руководитель проекта Нет файла Бесплатно (free) Управление проектом

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

18.08.2018    8154    Selikhovkin    15       

Принцип "Айсберг" 29

Статья Программист Пользователь Руководитель проекта Нет файла УУ Бесплатно (free) Управление бизнес-процессами (BPM)

Простой принцип, который стоит учитывать при автоматизации.

16.08.2018    9085    1c-intelligence    23       

Канбан в условиях российской действительности 71

Статья Системный администратор Бизнес-аналитик Пользователь Руководитель проекта Нет файла Россия Бесплатно (free) Управление бизнес-процессами (BPM) Управление проектом

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

08.08.2018    14854    MariaTemchina    63       

Что можно назвать проектом, а что нельзя, и каковы критерии успеха менеджера. Курс по управлению проектами, часть 1 63

Статья Бизнес-аналитик Пользователь Руководитель проекта Нет файла Россия Бесплатно (free) Управление проектом

Разберемся: что такое проекты в классическом понимании, почему строительство египетских пирамид проектом считать нельзя, почему многие "продуктовые" компании могут обходиться без проектного управления, каковы критерии успеха для руководителя проекта.

30.07.2018    11479    Selikhovkin    39       

Почему Agile превращается в Тяп-ляп. Кто виноват и что делать? 42

Статья Системный администратор Бизнес-аналитик Пользователь Руководитель проекта Нет файла Бесплатно (free) Управление проектом

В моей практике довольно много историй, когда компании, решившие внедрять гибкие методологии, начинали за здравие (Agile), а кончали за упокой - Do & Fix (делаем, как бог на душу положит). Попробуем разобраться, почему так происходит.

27.07.2018    10018    MariaTemchina    19       

Можно ли объять необъятное или чем Agile отличается от водопада? 64

Статья Системный администратор Бизнес-аналитик Пользователь Руководитель проекта Нет файла Бесплатно (free) Управление проектом

Что общего между управлением парусной яхтой и проектом по внедрению ERP-системы на предприятии? В данной статье я постаралась понятным языком описать разные подходы к проектному управлению, и разобраться при каких условиях та или иная методология может быть полезной при реализации проектов.

23.07.2018    9244    MariaTemchina    42       

Redmine для управления ИТ: практический опыт обширного внедрения opensource-системы 72

Статья no Нет файла Бесплатно (free) Управление проектом

Золотарева Екатерина делится опытом внедрения Redmine в своей компании. Она описывает процессы, которые удалось автоматизировать с помощью OpenSource-системы. Рассказывает о преимуществах и недостатках Redmine. Раскрывает тему применения плагинов к программному продукту, а также приводит полезные источники платных и бесплатных плагинов.

16.07.2018    23193    Hissin    15