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

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

Анализ и управление - Анализ и проектирование ИТ-систем

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

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

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

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

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


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

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

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

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


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

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

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

Что в итоге?


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

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

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

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

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

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

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

Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. lunjio 65 26.12.18 20:06 Сейчас в теме
Согласен с автором в части наблюдений, вот почему не получается просто взять написать и забыть ? нужно поискать подвох, подумать про производительность. Так же бывает и обратное, сделал за 15 минут, а потом мозг собирает картинку и ты понимаешь, что это не учел и то не учел и 1 строчка кода обрастает условиями и т.п.
Про русских людей - ну не надо так слишком уж прям, много русских людей очень ценные специалисты как на западе так и на родине, возможно имеется ввиду средний класс, а не высококвалифицированные специалисты ?
В целом много полезного, но не буду все критично принимать. В копилку однозначно.
2. swimdog 747 27.12.18 00:02 Сейчас в теме
А абзацами с заголовком читать намного легче. В заголовке суть, в абзаце детали. Даже такая длинная статья была прочитана за 2 подхода.
3. v3rter 27.12.18 13:46 Сейчас в теме
Если методика флакона подошла к 1С Документообороту, то должна подходить и к CRM-системам: Битриксу24, Амо и т.п. Пробовали что-нибудь в этом направлении?
4. 1c-intelligence 12622 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 Сейчас в теме
Так а где, собственно, сам Флакон?? Или эта статья - зондирование рынка?
Оставьте свое сообщение

См. также

Бесплатный сыр в мышеловке, или Как бизнес-аналитику прокачать себя самостоятельно

Мотивация, лидерство и личная эффективность Анализ и проектирование ИТ-систем Бесплатно (free)

Приняли решение стать аналитиком 1С, но не знаете, как? Попробуем сконструировать курс под свой уровень развития так, чтобы все нужные нам материалы были максимально доступны и требовали минимальных финансовых вложений. Руководитель отдела сопровождения финансового учета компании САМОКАТ Анастасия Штей на конференции Infostart Event 2022 Saint Petersburg рассказала, как искать и систематизировать нужную информацию об ИТ-анализе, чтобы прокачать свой уровень знаний аналитика 1С самостоятельно.

17.05.2023    988    ashtey    1    

5

Бухгалтерский и Управленческий учеты - антагонисты, симбионты или альтернативы?

Анализ и проектирование ИТ-систем Россия Бухгалтерский учет Управленческий учет Бесплатно (free)

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

25.04.2023    717    DemetrKlim    22    

8

Радио "Аналитик", выпуск 15. О текстах в интерфейсах с Александром Марфициным

Анализ и проектирование ИТ-систем Бесплатно (free)

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

03.04.2023    299    Radio_Analyst    0    

3

Кого найти? Кому отдаться? (если вы решили стать 1С аналитиком). Часть 2

Анализ и проектирование ИТ-систем Россия Бесплатно (free)

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

20.03.2023    1293    Senator_I    4    

7

Радио "Аналитик", выпуск 14. О когнитивных искажениях, сервисе UX CORE и проекте KeepSimple c Вольфом Алексаняном

Анализ и проектирование ИТ-систем Бесплатно (free)

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

20.03.2023    261    Radio_Analyst    0    

3

Дизайн-мышление как инструмент предпроектной аналитики

Анализ и проектирование ИТ-систем Бесплатно (free)

Алексей Таченков на Infostart Event 2021 Moscow Premiere поделился своим опытом внедрения дизайн-мышления в процесс предпроектного исследования, а также рассказал об инструментах для анализа и улучшения пользовательского опыта. Методика будет интересна для разработчиков, которые хотят создавать качественные продукты и удовлетворять потребности пользователей.

10.03.2023    602    tachenkov    0    

5

Радио "Аналитик", выпуск 13. О книге Карла Вигерса "Разработка требований к программному обеспечению" с Александром Байкиным

Анализ и проектирование ИТ-систем Бесплатно (free)

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

06.03.2023    2150    Radio_Analyst    0    

5

Куда пойти? Куда податься? (если вы решили стать 1С аналитиком). Часть 1

Анализ и проектирование ИТ-систем Бесплатно (free)

В статье рассматривается путь в профессию аналитика 1С. В первой части статьи рассмотрю, какие есть направления для обучения. Рассмотрим специализацию аналитиков и как выбрать нужную.

02.03.2023    1645    Senator_I    13    

6

Бизнес-аналитик 1С: универсальный солдат или кто?

Анализ и проектирование ИТ-систем Внедрение ИТ-системы Бесплатно (free)

Анастасия Штей рассказала на конференции Infostart Event 2021 Post-Apocalypse, как вырасти до бизнес-аналитика, и через какие испытания придется пройти. В своем докладе она рассуждает, почему эта профессия еще не до конца сформирована на российском рынке, и какие скилы должен качать бизнес-аналитик, чтобы стать профессионалом.

01.03.2023    1293    ashtey    0    

7

Гармония порядка и гибкости

Бюджетирование и планирование Анализ и проектирование ИТ-систем Бесплатно (free)

Сегодня мы порассуждаем, можно ли найти идеальный баланс между гибкостью в принятии решений и внутренними правилами, что такое БДР и метод условных начислений, и какое вообще отношение ко всему этому имеет 1С.

15.02.2023    623    alex_safin    1    

7

Радио "Аналитик", выпуск 11. О создании продуктов с Сергеем Колосковым

Анализ и проектирование ИТ-систем Бесплатно (free)

В одиннадцатом выпуске подкаста Радио “Аналитик” обсудили, как найти актуальную проблему для создания продукта, как проверить идею продукта на востребованность и как сделать продукт привлекательным для потенциальной аудитории.

06.02.2023    348    Radio_Analyst    0    

3

Радио "Аналитик", выпуск 9. О ванильном мороженом и обучении аналитиков 1С с Анастасией Штей

Анализ и проектирование ИТ-систем Бесплатно (free)

В девятом выпуске подкаста Радио “Аналитик” обсудили, какое обучение доступно будущим аналитикам 1С сейчас, с какими трудностями могут столкнуться выпускники курсов и что ожидают от аналитиков работодатели.

13.01.2023    468    Radio_Analyst    0    

3

Пример автоматизированного управления публикацией списка баз

Анализ и проектирование ИТ-систем Администрирование СУБД Бесплатно (free)

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

29.11.2022    948    Elaks    3    

9

Мобильные приложения 1С: зачем они бизнесу? Обзор + 7 идей применения

Мобильная разработка Анализ и проектирование ИТ-систем Бесплатно (free)

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

31.10.2022    1414    ystetsenko    1    

2

Простой пример частного технического задания (ЧТЗ) для 1С-ника

Анализ и проектирование ИТ-систем Бесплатно (free)

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

27.10.2022    6237    Koder_Line    3    

6

Аналитик 1С: так ли он нужен?

Анализ и проектирование ИТ-систем Управление командой Внедрение ИТ-системы Россия Бесплатно (free)

Не все клиенты понимают, зачем на проекте внедрения или сопровождения 1С аналитики. Разве с поставленными задачами не справится хороший программист? Давайте разбираться вместе с экспертами компании «Внедренцы и Программисты».

13.10.2022    3307    ystetsenko    16    

5

Как донести здравый смысл до заказчика. Инструменты архитектора

Управление проектом Анализ и проектирование ИТ-систем Бесплатно (free)

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

05.08.2022    9921    Evil Beaver    17    

99

Дизайн-мышление в заказной разработке

Анализ и проектирование ИТ-систем Бесплатно (free)

Метод дизайн-мышления смещает приоритеты разработки на потребности пользователя. Но как понять, что пользователь хочет и учесть его подразумеваемые требования? О том, как с помощью эмпатии к пользователю и визуализации идей сделать удобный для заказчика продукт, в докладе на Infostart Event 2021 Moscow Premiere рассказала Мария Серёгина.

30.06.2022    2459    SerjoginaMaria    15    

8

Автоматизация vs оптимизация

Анализ и проектирование ИТ-систем Внедрение ИТ-системы Бесплатно (free)

Анализ и оптимизация бизнес-процессов становятся все более востребованными в проектах автоматизации, а с массовым переходом с 1С: УПП на 1С:ERP эта задача станет еще более актуальной. О том, как собрать полную картину реальных потребностей вашего заказчика, исходя из логики его бизнес-процессов, на конференции Infostart Event 2021 Moscow Premiere рассказала Елена Иванова.

27.06.2022    2761    e_ivanova    0    

11

Скальпель, зажим, … пластырь, валерьянка. Мы закончили..: инструменты работы бизнес-аналитика

Анализ и проектирование ИТ-систем Бесплатно (free)

Считается, что аналитику для работы на проекте достаточно уметь строить бизнес-процессы в одной-двух популярных нотациях. Но это не так, потому что работа аналитика гораздо разнообразнее и не ограничивается рисованием схем. О том, какие инструменты пригодятся аналитику и помогут ему сделать свою работу комфортной и удобной, на конференции Infostart Event 2021 Moscow Premiere рассказала руководитель отдела сопровождения финансового учета компании «Самокат» Анастасия Штей.

23.06.2022    4942    ashtey    0    

38

Эмпатия и системный подход в сборе требований и составлении ТЗ

Анализ и проектирование ИТ-систем Внедрение ИТ-системы Бесплатно (free)

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

10.06.2022    2286    kacelena    2    

14

Аналитика и BI. Белые пятна рынка и тренды, которые нельзя игнорировать

Анализ и проектирование ИТ-систем Консолидация данных Бесплатно (free)

Мир вычислений бурно развивается, и потребность анализировать «большие данные» уже плотно вошла в жизнь любой, даже маленькой компании. О том, какие исторические предпосылки привели к текущей ситуации на рынке BI-систем, и какие перспективы у этого развития, на митапе «Бизнес-анализ по данным базы 1С» рассказали представители компании «Консон» Евгений Скребанов и Иван Мищенко.

08.06.2022    1927    imischenko    0    

2

SAFe Epic (Эпик)

Анализ и проектирование ИТ-систем Бесплатно (free)

Перевод https://www.scaledagileframework.com/epic/, с переводом сопутствующих терминов, для понимания основного термина и варианта его использования.

06.06.2022    1440    malikov_pro    0    

4

ТЗ как обязательный атрибут в автоматизации. Реальные кейсы из 16-ти летнего опыта

Анализ и проектирование ИТ-систем Бесплатно (free)

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

01.06.2022    2469    user1551153    0    

7

Путь покупателя интернет-магазина (Customer Journey) с использованием УФМТП

Анализ и проектирование ИТ-систем Управленческий учет Бесплатно (free)

Недавно у меня вышла статья под названием «Универсальная функциональная модель торгового предприятия (УФМТП) в нотации IDEF0». И одно из пожеланий читателей было пояснить подробнее, как я лично пользуюсь этой моделью и как вообще ее можно применять на практике. В этой статье я выполню просьбу читателей. И на примере взаимодействия покупателей с интернет-магазином продемонстрирую практическое применение этой модели.

12.05.2022    1505    raiml    2    

5

Универсальная функциональная модель торгового предприятия в нотации IDEF0

Анализ и проектирование ИТ-систем Управленческий учет Бесплатно (free)

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

12.05.2022    3925    raiml    4    

7

Современные СЭД: курс на упрощенчество и подмена понятий

Документооборот и делопроизводство (СЭД) Анализ и проектирование ИТ-систем Внедрение ИТ-системы Управленческий учет Бесплатно (free)

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

12.05.2022    815    user1214797    5    

2

Business Objective Model или Модель бизнес-целей - где, зачем и как применять?

Анализ и проектирование ИТ-систем Бесплатно (free)

Модель бизнес-целей или Business Objective Model (далее BOM) - техника, которая захватила моё сердце и разум с первого взгляда. Простая и наглядная, она помогает избежать того, от чего так часто возникает недопонимание между бизнесом и теми, кто его автоматизирует.

23.03.2022    2566    SerjoginaMaria    18    

19

Power BI дешево или очень дорого?

Консолидация данных Анализ и проектирование ИТ-систем Бесплатно (free)

На онлайн митапе «Бизнес-анализ по данным базы 1С. Интеграция c платформами BI» выступил Петр Базелюк, CTO компании Digital Business. Петр рассказал, как запустить систему аналитики для полноценной цифровизации всего бизнеса, сравнил возможности подписок Free, Pro и Premium и подсказал возможные пути минимизации затрат.

18.02.2022    4348    pbazeliuk    3    

11

Какие риски и ответственность берет на себя бизнес-аналитик

Анализ и проектирование ИТ-систем Бесплатно (free)

Профессия бизнес-аналитика хотя и интересная, но полна неопределенности. Чем должен заниматься этот специалист, какими навыками обладать, за что отвечать? На эти вопросы попытался ответить исполнительный директор Инфостарта Александр Чавалах.

16.02.2022    4386    chavalah    8    

18

Как мы подружили "1С:Аналитику" и "Финансист". Практический опыт

Консолидация данных Внедрение ИТ-системы Анализ и проектирование ИТ-систем Бесплатно (free)

«1С:Аналитика» – достаточно молодой инструмент от фирмы «1С». О том, как его настроить и запустить для отображения консолидированных данных из различных баз, на митапе «Бизнес-анализ по данным базы 1С. Интеграция с платформами BI» рассказала Ирина Богданова – ведущий разработчик тиражного решения «Финансист» в компании WiseAdvice.

11.02.2022    4331    bogira    2    

8

Не надо делать мне как лучше, оставьте мне как хорошо

Анализ и проектирование ИТ-систем 1С:Франчайзи, автоматизация бизнеса Бесплатно (free)

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

08.02.2022    3602    SerjoginaMaria    37    

19

42 или главный вопрос по бизнес-процессам

Анализ и проектирование ИТ-систем Бесплатно (free)

Приветствую вас, уважаемые коллеги! Меня зовут Анастасия Штей, я – бизнес-аналитик 1С. Именно так я начинала свои доклады на INFOSTART EVENT 2021 Post-Apocalypse и INFOSTART EVENT 2021 Moscow Premiere. Мне очень близка тема бизнес-анализа, изучения подходов и практик моделирования бизнес-процессов и компетенции бизнес-аналитика. И сейчас я запускаю на Инфостарт серию статей, а уже скоро и курс, посвященный основам моделирования и анализа бизнес-процессов.

07.02.2022    7268    ashtey    20    

25

Документальное оформление бизнес-процессов в проектах по автоматизации

Анализ и проектирование ИТ-систем Управление проектом Внедрение ИТ-системы Бесплатно (free)

При формировании проектной документации под конкретного заказчика важно использовать в качестве основного источника информации автоматизируемые бизнес-процессы. О том, как такой подход позволяет соблюсти правило полноты и непротиворечивости информации на митапе «Бизнес-аналитик. Роль в команде, компетенции, инструментарий» рассказал руководитель отдела экспертизы компании «Первый БИТ» Денис Галимов.

02.02.2022    9098    denisgalimoff    3    

23

Как бизнес-аналитик может повысить эффективность и прибыльность разработчиков

Управление ИТ-подразделением Анализ и проектирование ИТ-систем Бесплатно (free)

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

31.01.2022    2194    drmaxart    2    

8

Матрица компетенций аналитика 1С

Мотивация, лидерство и личная эффективность Анализ и проектирование ИТ-систем Бесплатно (free)

Тема мотивации сотрудников – одна из центральных в любой организации. Но, как и за что премировать работников, определиться сложно. В компании ФТО решили, что нужно сформировать матрицу компетенций, присвоить каждой определенное количество баллов, и уже на основании такой независимой оценки распределять премиальные. Подробнее о системе рассказала руководитель аналитиков 1С проектного отдела компании ФТО Анна Бирюкова.

28.01.2022    5035    abir    20    

19

Экспресс-обследование и реинжиниринг бизнес-процессов

Внедрение ИТ-системы Управление проектом Анализ и проектирование ИТ-систем Бесплатно (free)

Проведение обследования – это первый этап работы на проекте. От того, как этот этап пройдет, и какие результаты будут получены, будет зависеть дальнейший исход вообще всего проекта. О проведении обследования предприятия для целей управленческого учета на основе МСФО рассказал Генеральный директор ООО «Рэй Консалтинг» Николай Шилкин.

26.01.2022    3332    RayCon    1    

16

Бизнес-аналитики 1С: спрос есть, но кто они?

Управление ИТ-подразделением Внедрение ИТ-системы Анализ и проектирование ИТ-систем Бесплатно (free)

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

24.01.2022    8100    otkalo    0    

19

Роль и задачи аналитика в проектной команде при внедрении 1С

Управление командой Внедрение ИТ-системы Анализ и проектирование ИТ-систем Бесплатно (free)

Типовые продукты фирмы «1С» становятся все более гибкими, и функция разработки или изменения для них очень часто вообще не требуется или требуется точечно, поэтому для подобных проектов появился отдельный специалист – аналитик 1С. Какие у него задачи, и чем он отличается от системного аналитика и бизнес-аналитика, рассказал руководитель отдела экспертизы компании «Первый БИТ» Денис Галимов.

19.01.2022    11622    denisgalimoff    8    

21