В разборе статьи РБК я указал, что одной из особенностью руководства проектами является управление функциями, а не людьми.
Поговорим немного об этом подробнее.
В классическом управлении мы всегда имеем дело с человеческими личностями. У этого факта есть достоинства и недостатки.
Достоинством в обсуждаемом контексте является принципиальная возможность мотивации людей, т.е. заинтересовать их тем что они делают.
Недостатком же - человеки такие человеки: они болеют, пьют, разгильдяйничают, ошибаются и вообще не очень надежны.
В управлении проектами же мы имеем дело с функциями. В силу определения проекта (ограниченность в ресурсах и времени) и особенностей проектной деятельности (она осуществляется параллельно обычной деятельности компании и надфункциональна) РП не работает с людьми напрямую: он работает с отделами как с функцией. И с этой точки зрения достоинства и недостатки меняются местами.
С одной стороны функция практически не зависит от человеческого поведения, эти риски могут быть минимизированы на этапе разработки проекта.
А с другой стороны функцию невозможно мотивировать. Отделы и функциональные единицы всегда будут воспринимать проекты как дополнительно навешанный на них объем, который мешает выполнению их прямых обязанностей. С точки зрения результатов работы проекта: в лучшем случае функция его не увидит, в худшем же - объем ее работы увеличится, что тоже не особо радует.
В этом, собственно, и причина сопротивления реализации проекту со стороны линейных сотрудников, они видят надвигающийся на них непонятный геморрой, а что там в нем и чем это им лично грозит - непонятно. Из очевидных опасений: всю потенциальную прибыль и экономию естественно получит компания, линейке ничего не обломится, а если и обломится в виде облегчения рабочей жизни, то за этим может следовать сокращение. Вот и еще одна причина противодействия: проект создает некую тревожную неизвестность.
Эта неизвестность как раз описывается неофициальной расшифровкой подхода LEAN - Less Employees Are Needed.
В процессе написания заметки я понял, что у меня выше изложено классическое определение отчуждения труда по Марксу:
Отчуждение труда - это превращение деятельности человека и ее результатов в самостоятельную силу, господствующую над ним самим и враждебную ему, и связанное с этим превращение человека из активного субъекта в объект общественного процесса.
Так проектная деятельность и выглядит со стороны представителей функции и линейного персонала. Именно осознание этого противоречия дает понимание, почему так важно воспринимать исполнителей и представителя линейного персонала как часть проектной команды, это помогает предвидеть дополнительные риски и работать с ними.
Если хотите подискутировать на тему, то добро пожаловать в @scrllock.
Учитывая ограничения формата я буду копировать сюда цитаты из статьи и комментировать. Разбор будет состоять из двух частей, первая - пройдемся по тексту и разберем основные тезисы, а потом выскажу мое мнение по поводу общего тона статьи.
Итак, с нами играет Денис Мочалов, директор продукта ELMA365 Проекта. Я не знаю кто это, что это и специально не гуглил дабы максимально обсуждать статью, а не автора или его работу.
Статья позиционируется как описывающая методы избегания конфликта интересов и в целом, направлена на облегчение коммуникации внутри проекта. Наверное. Но, есть нюансы, давайте разбираться.
Цитата:
Приведу пример из практики. На проекте импортозамещения системы документооборота в госкорпорации мы столкнулись со следующей ситуацией. При сдаче работ появились критические замечания со стороны рабочей группы заказчика: рядовые сотрудники сопротивлялись переходу на новую систему. Проблема в итоге масштабировалась настолько, что под угрозой оказалось финансирование дальнейших контуров автоматизации.Нам пришлось дополнительно обучать сотрудников, но это привело к дополнительным финансовым затратам и переносу сроков сдачи проекта. Этой ситуации можно было избежать с помощью правильно выстроенного управления заинтересованными сторонами.
О чем нам говорит эта ситуация? О том, что проект фактически был провален. Как РП и внедренец с достаточно большим списком завершенных проектов я вижу здесь два очень больших провала:
- судя по всему рядовые сотрудники вообще не были в курсе изменений ИЛИ их мнение в принципе не учитывалось в процессе реализации проекта. Это нам говорит о серьезном провале на этапе определения проекта и том, что проектная команда была составлена неверно.
- если вы столкнулись с необходимостью дообучать сотрудников на этапе внедрения проекта и что еще важнее, вам пришлось привлекать дополнительные ресурсы к обучения - подготовка в внедрению также провалена.
Те, кто меня знает и со мной общается, скорее всего помнят как меня бомбило весь последний проект на тему вовлеченности местной команды и рядовых сотрудников в реализацию проекта и сколько яда я на них вылил. Но мы были готовы к проблемас, учли их в плане проекта, составили план действий и эти действия были корректно задокументированы, обсуждены и согласованы, а следовательно никаких «угроз финансированию» даже близко не наблюдалось. Соответственно, в нашем случае проблемы с операционной командой не привели ни к срыву проекта, ни к дополнительным серьезным расходам, более того, клиент даже не заметил, что у нас были какие-то явные сложности.
Цитата: При командной работе в крупном проекте важно выявить роли его участников и определить зоны ответственности. Лицо, которое так или иначе связано с проектом, называют стейкхолдером или заинтересованной стороной (или по ГОСТ 51897-2002 — «причастной стороной»).
0 вопросов, все верно, ссылка на ГОСТ доставляет отдельно. Этот тезис запомним, он важен для дальнейшего разбора. Далее автор разбирает разницу между классической и матричной структурами организации. Разница между ними как-то невнятна, но мы сейчас не об этом. В обеих структурах нижний уровень пирамиды у него указан как «исполнители» для классической модели или «руководители бизнес подразделений». Отсюда мы делаем вывод, что автор вообще не воспринимает линейный персонал как что-то достойное внимания.
Потом начинается дичь. Цитата из описания ролей в проекте: - рядовые пользователи дают обратную связь, по большей части негативную, но не имеют рычагов влияния на проект;
Автор в начале статьи пишет, что проект был под угрозой остановки финансирования из-за сопротивления рядовых сотрудников, а сейчас пишет, что они не имеют влияния на проект. Они чуть было не угробили твой проект, ты уверен что у них нет рычагов влияния?
Цитата: Коммуникации между стейкхолдерами — это всегда омниканальность: CRM, почта, мессенджеры, а также личные встречи и мероприятия. Свести все в один канал, как бы этого ни хотелось, никак не получится. Поэтому руководитель проекта берет на себя несколько ролей: и психолога, и организатора, и управленца, а иногда отчасти даже родительской фигуры.
Тут не очень понятен переход между омниканальностью и ролями РП, но суть не в этом. Сейчас бомбить буду уже я. Коллеги, вы там вообще без меня совсем с ума посходили? Какой из РП психолог, управленец и родительская фигура? Это именно то поведение, которое загубит весь проект. Два основных человека в проекте, РП и руководитель внедрения (РВ) - это люди, которые не могу себе позволить быть хоть немного человечными, потому что именно их волей проект двигается. Если я, как РП, начну проявлять эмоции по отношении к любой функции - это моментально бьет по всем остальным функциям. Если РВ начнет проявлять человечность к подчиненному ему запускающему тренеру, то моментально к нему возникнут вопросы от качества, локальной команды и прочих. Типа почему он, а не мы? Не делайте так, коллеги, это непозволительная роскошь в именно проектной деятельности, в отличие от нормальной. В проекте вы не руководите людьми. Вы руководите функциями и именно слаженность работы функций, а не людей реализует проекты. Проект не может зависеть от Никиты Иванова, потому что он может быть разгильдяем, проект должен зависеть от ИТ разработчиков и относиться к Никите вы должны как в функции, а не как к человеку. И именно поэтому в прошлой статье я говорил о правовом поле проектной деятельности. В компании могут быть разной степени расхлябанности сотрудники, но компания потому и компания, что она может из стада сделать функцию. И РП и вообще проектная деятельность связана с функциональными единицами, а не с конкретными индивидами.
Причем автор это явно понимает, но, возможно пытается сыграть на поле ассертивности, вовлеченности и вообще все РП такие проработанные лапки…
Цитата: Руководитель проекта взаимодействует со всеми стейкхолдерами: определяет локомотивные функции, управляет их влиянием, чтобы усилить позитивные возможности ролей и минимизировать негативные. Таким образом, руководитель играет ключевую роль в успехе проекта.
0 вопросов, хрен поспоришь.
Цитата:
Не все люди, способные влиять на ход проекта, в нем заинтересованы. Например, для HR не так важно, в какие сроки будет разработано и внедрено новое ПО. Руководитель проекта должен знать интересы всех участников. Для того чтобы систематизировать данные, он может использовать матрицу RACI.
Начинается моё любимое. Да, автор знает что есть что-то называемое на RACI, но не знает что уже много лет в подобных проектах используется расширенная модель RASIC или RASCI. Основная разница в том, что RACI — классическая матрица распределения ответственности (Responsible, Accountable, Consulted, Informed), а RACIS (RASCI/RASIC) это ее расширенный вариант с добавлением роли S (Support/Supportive), чтобы в явном виде включить роль поддержки. И весь прикол в том, что именно неверный выбор матрицы и привел товарища в то место, где он в итоге оказался, так как рядовой, линейный персонал и включается в такие проекты как Support, потому что именно они могут сказать как лучше сделать, как организовать обучение и переход на новые системы.
Кстати, мой последний разбор на сайте - как раз про нее, про RACIS.
Подведем итог. Когда-то давно я писал в одной из моих заметок про ИТ о том, что если вы проходите какую-то новую технологию в институте, то ей уже года 3-5, а если ваш учебник 2-го издания, то этой хренью уже давно никто не пользуется. Сейчас тоже самое происходит в российском операционном управлении и управлении проектами. Всякие странные люди пишут всякие странные статьи, лишенные внутренней логики, всякие автозаводы внедряют что-то лишь бы было и все это происходит на фоне общего отношения к линейному персоналу через губу, типа вы, смерды, будете делать то, что я тут вам придумал, ведь я прочитал книжку ДАО Тойоты, у меня в подписи написано Руководитель проектов и я точно знаю как лучше. И это, как по мне, очень грустно, потому что мы теряем очень большой пласт компетенций и идей, которые вполне могли быть дать хорошего пинка российской системе управления. А я считаю, что ей это прям необходимо.
Если хотите подискутировать на тему, то добро пожаловать в @scrllock. Всякие прочие мысли тут: @myhorop
Шпаргалка для технических руководителей, лидов и просто всех, кто так или иначе связан с управлением командами.
Почти четыре года назад я присоединился к проекту Эсборд в роли CTO. Передо мной стояла амбициозная задача: в короткий срок, на частные деньги, без стартовой команды выпустить абсолютно новый продукт для корпоративного рынка — замену Miro в РФ с возможностью поставки в контур компании, а также работой в облаке как замену существовавшему на тот момент B2C-решению.
Менее чем через год я сидел в офисе одного крупного банка и помогал DevOps-команде установить и запустить наш сервис. Установка уложилась в один рабочий день. Мы запустили пилот.
Дальше была череда новых вызовов, побед и крупных контрактов. Рост команды, развитие. На каждом этапе требовались различные навыки.
И в какой-то момент я понял, что многие знания уже начинают стираться из памяти, и мне захотелось их где‑то собрать, структурировать.
И лучшим местом для этого стал наш «Эсборд» - сервис, в создание которого эти знания были вложены.
1. Проект движется со скоростью решений, а не задач. Если решения принимаются неделями, никакой таск-менеджер не спасёт.
2. Контур «что мы не делаем» важнее идеального плана. Проекты разваливаются не от отсутствия идей, а от их избыточности. Важно не только планировать, но и отсекать, что точно не в этом спринте, не в этом релизе, не в этом проекте.
3. Психологический контракт важнее регламента. Люди работают не по бумажке, а по внутренним договорённостям. Кому доверяют, кого боятся подвести, а с кем не хотят иметь дело.
4. Хороший менеджер не тушит пожары, а убирает их причины. Настоящая работа — устроить систему так, чтобы пожаров становилось меньше.
Подписывайтесь на канал «Законы сохранения бизнеса», там про управление маленьким отделом и большим бизнесом — как выстроить процессы и направить энергию в развитие, а не в трение.
ЛИМС — это автоматизированная лабораторная система, которая собирает и обрабатывает (управляет) данные (ми). Некоторые считают, что ЛИМС это набор из электронных журналов, используемых Лабораторией, но настоящая ЛИМС это специализированная программа, которая служит для ведения учета, расчетов, отчетов, контроля и т. д.
ЛИМС это часть лабораторной деятельности
ЛИМС является системой, и как минимум объединяет в себе несколько журналов, позволяет использовать информацию из одних журналов в других, например использовать сведения об оборудовании в журнале по измерениям (испытаниям), или использовать сведения из журнала по отбору проб в журнале выдачи протоколов. За счёт объединения в одной системе нескольких журналов, справочников можно добиться новых свойств и функций ведения записей. Получается, что за счёт системности достигают эмерджментные свойства.
Функционал ЛИМС может покрывать все процессы в лаборатории
Одной из важных особенностей ЛИМС являются свойства управления записями, которые недоступны при использовании бумажных журналов. Как правило при внедрении ЛИМС у лаборатории возникают требования о необходимости соблюдения требований ГОСТ ISO/IEC 17025-2019 к ведению записей изложенных в п. 7.5 и п. 8.4. Понятно, что в ЛИМС должна быть возможность фиксации результатов, отслеживания изменений, запрет изменений, архивирование, резервное копирование. В той или иной форме все производители ЛИМС стремятся всё это реализовать. Конечно бывают не очень удобные и практичные формы реализации, но в любом случае можно запрограммировать, чтобы автоматически записывались дата, время внесения и изменения данных, пользователь и информация о нём. При этом пользователь не будет иметь возможность редактирования этой информации.
Но это всё в ЛИМС, а вот если задуматься, то становится понятно, что на бумаге этого не обеспечить.
Например, сотрудник может заполнить журнал с результатами не в момент проведения испытаний (измерений), а позже или даже в другой день, ведь информация о времени и дате вносится им же, если и вносится вообще.
Тоже самое касается изменений, всегда можно внести исправление и подписаться другой датой. Можно вообще целиком переписать лист измерений (первичный протокол) и даже журнал измерений. При необходимости можно и исправления в журнале внести любой датой.
Ведение записей на бумаге не обеспечивают выполнение требований к техническим записям и их изменению. Без полноценной ЛИМС реализовать все требования к техническим записям не получится
Практика показывает, что лабораториям трудно успешно внедрить ЛИМС. Основные ошибки при внедрении ЛИМС не сильно отличаются от ошибок внедрения других информационных систем:
Отсутствие внятного технического задания на внедрение. Как правило при внедрении ЛИМС лаборатория берёт техническое задание поставщика. Понятно, что ту часть, которая о функциях и возможностях программы, менять после выбора конкретной программы не стоит, но есть ещё часть технического задания, которая касается внедрения. И вот к этому разделу ТЗ необходимо уделить как можно больше внимания;
Лаборатория тащит в ЛИМС все свои печатные/рукописные формы ведения записей. Ну здесь наверно пояснять не надо. Если вы переходите на электронные записи, то надо отказываться от старых бумажных. Возможно они были вами оптимизированы и удобны в заполнении, но в программе однозначно всё будет не так. Не стоит держаться за свои сдвоенные и строенные таблицы;
Процессы, которые лаборатория хочет автоматизировать, в системе менеджмента прописаны не чётко, есть неясности и не точности в описаниях, не приписано поведение сотрудника при выборе альтернативных вариантов. Процесс не является "прозрачным". Об этом можно говорить долго, и это тема вообще отдельно должна рассматриваться. Разработчик и внедренец ЛИМС часто сталкивается с тем, что лаборатория вроде как документировала процессы, прописала формы записей. Но по факту присутствуют не документированные записи, и поведение сотрудника при возникновении альтернативных вариантов не всегда прописано. То есть какие-то действия происходят, но происходят они по привычке или потому что руководитель сказал сделать так, а в СМ(К) это не включали. Вот простой пример - "процесс регистрации пробы". Казалось бы зарегистрировать пробу это очень просто, и весь процесс описывается двумя предложениями. "Сотрудник принимающий пробу вписывает информацию в журнал (приложение 1). Номер присваивается по порядку в журнале." Но здесь кроются разные нюансы. Например лаборатории могут использовать специфическую кодификацию/нумерацию проб, иметь несколько журналов регистрации, каждый под свой вид проб (скажем по объектам, по государственному заданию и отдельно платные), по подразделениям также могут делить, да и состав вносимой информации может сильно отличаться. Дополнительно сотрудник может делать приписки в журнале между строк с какой-то ещё информацией о пробе (например указывать состояние пробы или примечание к отбору проб);
Разновидностью третьей ошибки является и не совсем правильное выполнение методик. Если ЛИМС предполагает, что будут вестись записи и расчёты по методикам, то необходимо очень хорошо прописать последовательность действий персонала по внесению этих записей и хорошо проанализировать формулы расчёты. К сожалению встречается в практике недопонимание методик персоналом, а потом это всё ещё тащится и закрепляется в ЛИМС;
Серьёзной ошибкой лаборатории является неготовность переделывать документацию СМ(К) под ЛИМС. Внедрение ЛИМС в любом случае меняет процессы в лаборатории и это всё должно быть отражено в документации СМ(К). К сожалению и со стороны разработчиков ЛИМС не всегда есть люди, хорошо разбирающиеся в этом;
Лаборатория не готова проводить валидацию ЛИМС. Валидация подобного ПО фактически является обязательной, так же как валидация расчётов в электронных таблицах. Лаборатории стараются получить подтверждение от разработчиков, но ведь в процессе внедрения вносятся множество изменений и продукт, установленный у одного заказчика, может сильно отличаться от продукта у другого заказчика. Конечно поставщики ЛИМС предъявляют какие-то сертификаты на своё ПО. Но подобная сертификация у нас в стране не регулируется и такие сертификаты выдают не аккредитованные органы, что нарушает закон о техническом регулировании (184-ФЗ), и следовательно никакой силы такие красивые бумажки не имеют.
Лаборатория со своей стороны не сформировала группу ответственных за внедрения. Ну эта ошибка везде присутствует. С одной стороны у разработчика должна быть команда внедрения с руководителем проекта внедрения, а с другой стороны лаборатория тоже должна иметь ответственных людей, которые обязуются довести это внедрение до конца. Уполномочить ответственных можно приказом или каким-то ещё способом, принятым в организации. Естественно, что ответственный за внедрение должен обладать необходимыми полномочиями, чтобы менять документы СМ, составлять ТЗ, планировать валидацию и т. д.;
Ну и последняя ошибка - это отсутствие целеполагания во внедрении. Нельзя правильно внедрить то, что не известно зачем внедряется. Бывает что высшее руководство принимает такое решение, потому что у других есть или какой-то регулятор требует, но не ставит правильных целей. Такое внедрение ради внедрения никому не нужно и как правило проваливается.
Если мы внедряем что-то новое в лаборатории, да и в любой деятельности, необходимо сначала поставить ЦЕЛЬ. При чем само по себе внедрение нового целью не является. Цель должна быть описана и визуализирована. Если цель можно описать и визуализировать, то она реальна и достижима.
Какие же цели может ставить себе лаборатория?
Автоматически выдавать протоколы испытаний для уменьшения ошибок и человеческого фактора.
Автоматически принимать заявки и пробы, чтобы легче было отслеживать и контролировать движение проб и сроки проведения работ.
Получать точные и подробные отчёты по работе лаборатории без запроса.
Избавиться от использования (заполнения) рукописных форм.
Ускорить работу лаборатории (хотя такую цель надо ставить с осторожностью).
Можно выбрать несколько непротиворечивых целей, для каждой определить критерий достижения. Например цель по формированию отчётов будет достигнута, если можно будет сформировать целевой отчёт за шесть месяцев работы.
Критерии достижения целей необходимо прописывать для каждой цели, в общем то это является частью визуализации. Критерии позволяют нам сосредоточить внимание и обозначить границы, после прохождения которой можно считать проект внедрения завершённым.
Если в организации используют какие-то системы скоринга или KPI при премировании, то критерии достижения целей позволяют мотивировать ответственных за внедрение. Команда по внедрению должна собираться на этапе целеполагания, поскольку именно от целей зависит состав этой команды. В процессе формирования команды могут появиться и дополнительные цели и критерии их достижения.
Цель руководства, как правило, заключается в повышении контроля за работой сотрудников, автоматизации отчетов, снижении ошибок. А цель сотрудников - автоматизация своей работы, упрощение рутинных операций. Необходимо, чтобы руководство и сотрудники имело мотивацию, чтобы ЛИМС решала какие-то их серьезные проблемы, тогда внедрение возможно будет успешным.
Когда Руководство лаборатории определилось с целью и визуализировало её, необходимо сформировать команду ответственных за внедрение. В эту команду должны входить руководитель лаборатории, руководители отделов, менеджер по качеству, ключевые сотрудники - владельцы процессов. Желательно, чтобы размер команды не превышал 5-7 человек, иначе им будет трудно между собой договариваться.
На команду ложится тяжкое бремя:
1. Описание функциональных требований к ЛИМС;
2. Знакомство и выбор продукта из имеющихся на рынке;
3. Составление ТЗ на внедрение в соответствии с функциональными требованиями лаборатории и возможностями выбранного ЛИМС;
4. Согласование плана внедрения, представленного поставщиком ЛИМС;
5. Контроль процесса внедрения, общение с командой внедрения со стороны поставщика, уточнение требований, проверки ЛИМС и описание ошибок;
6. Валидация ЛИМС после внедрения.
Работы по внедрению могут растянуться на довольно долгий срок и состоят из многих этапов, поэтому команда должна периодически собираться и обсуждать текущий статус по внедрению, проблемные моменты, что еще нужно сделать на текущем этапе, согласовать какие-то изменения и доработки.
Выбрав какой-то ЛИМС их имеющихся на рынке или приняв решение разработать свое, каждая команда по внедрению сталкивается с проблемой написания ТЗ. Если выбран коммерческий вариант, то, как правило, фирма-поставщик ПО предоставляет своё ТЗ, слегка модифицированное согласно переданным ФТ. Не стоит ожидать там какой-то детализации планируемых решений. Всё будет описано общими обтекаемыми фразами, основной упор будет сделан на какие-то технические моменты (например используемый сервер базы данных). Для поставщика ПО основная проблема заключается в том, что для составления подробного ТЗ необходимо обследовать процессы лаборатории, ознакомить сотрудников с предлагаемыми решениями, определить и согласовать объем необходимых настроек, доработок и изменений. Это занимает довольно много времени, и поставщику ПО нет смысла этим заниматься до заключения контракта. Команда внедрения хотя и заинтересована в подробном ТЗ, но, во-первых, не обладает соответствующими знаниями и навыками (компетенциями), во вторых, не имеет полной информации о возможностях выбранной ЛИМС в настройке под нужды лаборатории, в-третьих, зачастую имеет неполное представление о процессах лаборатории из-за их непрозрачности, не ясности в описании, безальтернативности. Про проблему с прозрачностью процессов, я писал еще в начале. Нельзя написать хорошее ТЗ, если процессы "непрозрачные". Необходимо сначала внести в ясность в описание процессов, определить уровень детализации и т.д.
Про процессы можно долго говорить, но в целом понятно, что если лаборатория не может описать свои процессы, то при внедрении ЛИМС столкнется с проблемами.
Поэтому есть вариант разделить работу над ТЗ на три этапа:
1) Лаборатория пишет ТЗ и передает поставщику ЛИМС;
2) Поставщик ЛИМС проводит обследование лаборатории по ТЗ, выявляет нюансы
конкретной лаборатории, знакомит сотрудников с ЛИМС, в ходе знакомства и обсуждения выявляются многие скрытые вопросы и проблемы в процессах;
3) Поставщик по итогам обследования составляет конечное подробное ТЗ и согласовывает с
лабораторией.
Для поставщиков ЛИМС имеет смысл включать этап обследования в этапы по контракту и прописывать, что по итогам обследования будет уточнен перечень методик, журналов, форм и отчётов, которые будут внедрены в лаборатории (настроены поставщиком в ЛИМС). Некоторые формы и отчёты лаборатории можно в этот период изменить, если непосредственно в том же виде реализовать в ЛИМС не получится.
Документация по внедрению (базовый перечень):
Цель и функциональные требования — внутренний документ;
Техническое задание — внутренний документ и/или приложение к договору (контракту);
Договор, контракт, соглашение или иной документ с поставщиком (подрядчиком);
План работ, согласованный с поставщиком, приказ о закреплении ответственного со стороны лаборатории;
Акты, протоколы приема-передачи ЛИМС, запуска тестовой эксплуатации, приказ о закреплении ответственного (ых);
Журнал или протокол тестовой эксплуатации (ТЭ);
Акт или протокол передачи в опытно-промышленную эксплуатацию (ОПЭ), приказ о закреплении ответственного (ых);
План валидации, протоколы валидации, отчет о валидации;
Акт завершения ОПЭ;
Приказ о запуске в промышленную эксплуатацию.
Часть этих документов подготовит сам поставщик, но необходимо принимать в этом самое деятельное участие. Продвинутые поставщики ЛИМС могут предоставить документацию по ГОСТам серии 19 и 34, но строго говоря, для лабораторий это не обязательно. Следует следить за соблюдением формальных сроков и их переносом при необходимости. Документация по внедрению должна остаться в лаборатории для того, чтобы потом можно было к ней обратиться при проведении изменений, доработок и ревалидации ЛИМС. Также эта документация может понадобиться при аккредитации или очередном подтверждении компетентности, поскольку эксперты по аккредитации могут её запросить. До завершения внедрения (или в момент завершения) необходимо также издать новые документы (процедуры) СМ(К), в которых будет описана работа сотрудников лаборатории в ЛИМС.
Очень часто задают вопрос: «Почему же так сложно (дорого) автоматизировать процессы в лаборатории?»
Ответ тут на самом деле очень простой. В отличии от других сфер деятельности (бухгалтерия, кадры, производство), у лаборатории много процессов. Даже не так — очень много процессов. Во многих случаях каждый метод испытаний это отдельный процесс, в том числе с ветвлениями и циклами. А еще в каждой лаборатории даже одинаковые вроде бы процессы реализуются по своему, и какого‑то универсального решения тут нет. Поэтому нормальная автоматизация в виде внедрения программы, которая настраивается под все процессы, становится очень дорогой. Ну и понятно, что для быстрой реализации расчетов по различным методикам измерений и испытаний так или иначе необходимо использование каких‑то лоу‑код инструментов. Поэтому самый лучшей реализацией ЛИМС будет приложение‑конструктор с элементами ноу‑кода и лоу‑кода.
Но к сожалению не все разработчики подобных программ это понимают и продолжают следовать парадигме классической разработки
Почему каскадная модель не так «жёстка», как кажется, а Agile — не методология.
На написание статьи сподвигла статья с Хабра и обсуждения в чате одного сообщества по бережливому производству.
Хочу сразу обратить внимание, что здесь будем обсуждать ложную дихотомию в управлении проектами.
Споры о превосходстве Agile над Waterfall или наоборот давно стали клише в IT-среде. Однако корень этой дискуссии — фундаментальное непонимание сути обеих концепций. Agile часто ошибочно называют методологией, тогда как на деле это набор ценностей, а выбор реальных инструментов управления происходит между каскадной моделью (Waterfall) и итерационными подходами — Scrum, Kanban, XP. Почему этот нюанс так важен? Потому что смешение философии и инструментов ведёт к мифам, которые мешают эффективно управлять проектами.
Кажется, что waterfall (каскад) это старая и неповоротливая система
Agile — это ценности, а не методология
Манифест Agile, созданный в 2001 году, провозглашает четыре ключевые ценности:
Люди и взаимодействие важнее процессов и инструментов.
Работающий продукт важнее исчерпывающей документации.
Сотрудничество с заказчиком важнее согласования условий контракта.
Готовность к изменениям важнее следования первоначальному плану.
Это не инструкция «как управлять проектом», а напоминание о приоритетах. Agile не отменяет документацию или планирование — он лишь предостерегает от их абсолютизации. Например, детальное ТЗ необходимо при разработке ПО для автомобиля, но нужно меньше заострять на этом внимание в условиях полной неопределённости — например, для стартапа.
Если коротко, то Аджайл - это крик души замученного разработчика
Waterfall: миф о жестком подходе
Каскадную модель традиционно изображают как жёсткую последовательность этапов: анализ требований → проектирование → разработка → тестирование → поддержка. Критики утверждают, что Waterfall не допускает изменений после завершения этапа, что якобы делает его непригодным для современных проектов. Однако на практике это утверждение неверно.
Собственно говоря, Waterfall манифеста нет, поэтому ориентируемся на заполнение документации в классической разработке. Есть такая нормативка, которую можно условно отнести к каскадной модели разработки - ГОСТ 19.102-77 Единая система программной документации (ЕСПД). Стадии разработки. Устанавливает стадии разработки программ и программной документации для вычислительных машин, комплексов и систем независимо от их назначения и области применения:
Техническое задание
Эскизный проект
Технический проект
Рабочий проект (Разработка программы, Разработка программной документации, Испытания программы Корректировка программы и программной документации по результатам испытаний)
Внедрение (Подготовка и передача программы)
Но в таких регламентированных отраслях, таких как разработка ПО по ГОСТам, процессы предусматривают корректировки. Например, ГОСТ 19.603-78 прямо регламентирует внесение изменений в документацию по двум причинам:
Устранение ошибок.
Развитие и усовершенствование продукта.
Рассмотрим пример из строительства: если при возведении дома инженеры обнаруживают слабый грунт, они не продолжают работу по изначальному плану, рискуя обрушением. Вместо этого корректируют проект (например, углубляют сваи), а затем обновляют документацию. Такой же принцип действует и в IT: даже в рамках Waterfall команды вносят правки в ТЗ или архитектуру, сталкиваясь с новыми данными.
Ведь в Каскаде обратная связь не запрещена, просто требуется документирование
Почему возникает миф о несовместимости?
Противопоставление Agile и Waterfall часто служит маркетинговым инструментом. Консультанты и тренеры упрощают сложную картину, создавая «чёрно-белый» нарратив: «старое vs новое».
Если немного утрировать, то противопоставляя гибкую разработку каскадной, говорят, что строители будут строить дом по неправильному проекту без изменений, пока всё не рухнет, и только потом встанут, отряхнутся от пыли и скажут: - Давайте заново начнем.
Однако в реальности:
Waterfall не запрещает гибкость. Многие проекты в аэрокосмической отрасли или энергетике успешно комбинируют детальное планирование с оперативными корректировками. Agile не отрицает документацию. В регулируемых индустриях (финансы, медицина, машиностроение) документирование остаётся критичным, даже если команда разработки работает по Kanban или Scrum. Ключевое различие — не в наличии или отсутствии изменений, а в формализации обратной связи. Итерационные методы (Scrum, Kanban) встраивают её в процесс через короткие циклы (спринты), тогда как Waterfall требует явного согласования правок на каждом этапе.
Кажется, что это разные подходы, но это не так
Синтез вместо конфронтации: гибридные подходы
На практике чистые Waterfall, Kanban, Scrum встречаются редко. Большинство проектов используют гибридные модели. Например: Water-Scrum-Fall — детальная проработка этапов запуска и внедрения в стиле Waterfall с гибкой разработкой ядра продукта.
Такие подходы возникают не из-за «непонимания Agile», а из-за реальных ограничений: бюджетные циклы, требования регуляторов, необходимость согласования с внешними поставщиками. Например, команда может использовать Scrum для создания MVP, но переключиться на Waterfall при масштабировании продукта для enterprise-клиентов, где необходимы аудиты и сертификаты.
Например работа по непосредственной разработке ПО может идти итеративно, спринтами
Как же выбирать методологию? Нужно опираться на критерии, а не догмы Выбор между Waterfall и итерационными методами зависит от четырёх факторов:
Предсказуемость требований. Если цель проекта чётко определена и маловероятно изменится (строительство моста, разработка ПО для учёта налогов), Waterfall эффективнее. Если требования эволюционируют (стартап, исследовательский проект), нужны итерации.
Стоимость изменений. В разработке мобильного приложения правка дизайна в процессе дешевле, чем перепроектирование атомной станции. Waterfall оправдан там, где ошибки чреваты катастрофическими последствиями.
Регуляторные ограничения. В банковской сфере или здравоохранении документирование и согласования неотъемлемы, что делает чистый Agile невозможным.
Культура команды и заказчика. Если стейкхолдеры не готовы к частым демонстрациям и изменениям приоритетов, попытка внедрить Kanban или Scrum приведёт к конфликтам.
Выбор методологии зависит от многих вводных. Но нужно понимать плюсы и минусы каждой.
Примеров неправильного применения Scrum полно. Тот же Scrumfall существует уже повсеместно, потому что команды гонятся за мифом чистого Agile, там где никакой гибкостью даже не пахнет. Отсюда и вылезает такая проблема как "усталость" от Scrum
Agile и Waterfall не конкурируют — они решают разные задачи. Манифест Agile напоминает о ценностях, но не даёт готовых решений, а Waterfall — не догма, а инструмент, который можно адаптировать. Когда выбираем методологию управления проектами, вместо вопроса «Что лучше — Agile или Waterfall?» стоит спросить:
Какова степень неопределённости требований?
Какие ограничения накладывают регуляторы или бюджет?
Насколько команда и заказчик готовы к гибкости?
Управление проектами в разработке ПО это тоже инженерная дисциплина и должно быть прагматичным. Важно:
Нужно отказаться от догм и мифов. Waterfall не означает «отсутствие изменений», Agile — «отсутствие документов».
Ориентироваться на ценности, а не методы. Даже в каскадном проекте необходимо внедрить частые коммуникации с заказчиком (ценность Agile №3).
Признать контекст. «Идеальная» методология не существует — есть инструменты для решения конкретных задач.
Когда следующий раз услышите: «Мы Agile, поэтому не пишем ТЗ», или «Это Waterfall, тут нельзя менять требования», — задайте вопрос: «А почему?». Возможно, за этим стоит не разумный выбор, а миф, которому не место среди инженерной культуры.
Agile ругают за пустые ритуалы, водопад — за медлительность. Но спор чаще идёт о форме, нежели о сути. Когда-то бюрократия — в духе Макса Вебера и его рационально-легальной модели — научила организации масштабироваться: стандарты, роли, предсказуемость. Цена этой масштабируемости — тяжёлый пересмотр решений и медленный разворот. Agile — следующий шаг эволюции: он учит быстро учиться в процессе поставки, а не только планировать. Смысл — в коротких циклах, где каждая итерация заканчивается работающим инкрементом и проверкой гипотез на реальности.
Противоречия между Agile и Waterfall нет. Можно рассматривать Waterfall как одну из конфигураций Agile, когда из-за требований/рисков команда выбирает очень длинный спринт с единым выпуском в конце.
Почему Agile часто не принимают
Generated by Nano Banana
1) Инертность «старого менеджмента»
Люди, воспитанные в логике годовых планов и phase-gates-модели, оптимизируют предсказуемость и контроль. Их KPI — «по плану и в срок», зачастую игнорируя выученные уроки. Итерации для них выглядят как «незавершёнка», а видимые переработки — как провал, хотя это нормальная цена за ранние факты.
Плюс срабатывает выученная модель: «сначала всё решает начальник, потом команда просто реализует». Agile переворачивает это местами: команде приходится чаще принимать решения, а менеджеру — мириться с тем, что путь меняется по дороге.
2) Нежелание разбираться в сути и областях применимости
Agile подменяют ритуалами и пытаются применять «везде одинаково».
Итерации тащат в зоны необратимых решений (критичные данные, публичные контракты, безопасность) — получаются дорогие ошибки, после чего делают вывод «Agile не работает».
Или, наоборот, объявляют «гибкость» синонимом хаоса: без Definition of Done, наблюдаемости, критериев «достаточно» и guardrails. Тогда Agile превращается в оправдание «делать что хотим».
В обоих случаях это не Agile по смыслу, а просто плохо настроенный процесс с другим названием.
3) Конфликт с системой мотивации и корпоративным планированием
Топ-менеджмент пишет годовые планы с KPI, спускает их на линейных менеджеров и одновременно требует «работать по Agile». На бумаге — спринты и бэклог, в реальности — жёстко зафиксированный объём, сроки и метрики запуска «как в плане».
В таких условиях Agile на линейном уровне превращается в пародию:
команда должна делать вид, что «гибко адаптируется»,
но её оценивают по тому, насколько она не отклоняется от изначального годового плана.
Любая попытка честно скорректировать курс по результатам итерации воспринимается как «неисполнение плана», а не как нормальное обучение. Естественно, после такого у людей возникает стойкое отвращение к слову Agile.
Неприятие нового: уроки MBO
Generated by Nano Banana
Само по себе неприятие Agile — не что-то уникальное. Почти любое серьёзное управленческое новшество проходит долгий цикл — десятилетиями — через фазы: страх → неприятие → торг → принятие → базовая норма. Хороший пример — **Management by Objectives (MBO) Питера Друкера: когда-то идея управлять через согласованные цели, а не только через приказы сверху, пугала и казалась «теорией консультантов»; компании проходили через торг — цели формально ввели, но часто просто переписывали их из планов руководства. Сегодня MBO и его наследники (KPI, OKR) стали фоном: почти никто не спорит, что у команды должны быть понятные цели, спорят уже о том, как именно их формулировать. С Agile происходит тот же процесс, только объект изменений другой: не сами цели, а способ движения к ним — длинными монолитными циклами или короткими витками обучения.
Другие знакомые сюжеты
Точно такой же паттерн можно увидеть и в более близких примерах:
Удалённая работа и онлайн-обучение.
Ещё недавно идея «команда работает из дома» или «учиться можно онлайн» воспринималась как временная мера или вынужденный компромисс. Сейчас онлайн-форматы стали частью нормы, хотя до сих пор есть те, кто не принимает это как состоявшийся факт.
Гигиена и мытьё рук медперсоналом.
Когда-то требование мыть руки между пациентами вызывало яростное сопротивление и воспринималось как сомнение в профессионализме врача. Сегодня отказ от гигиены — маргинальное поведение, а не «альтернативный подход».
Во всех этих историях новое сначала кажется опасным, лишним или «модой», затем идёт долгий период торга и полумер, и только потом наступает стадия, когда вчерашняя инновация превращается в baseline — фон, с которого начинается следующий виток изменений.
С Agile, скорее всего, будет то же самое: через какое-то время спорить будут не о том, «нужен ли Agile в принципе», а о том, как именно конфигурировать процессы и архитектуру работы под конкретную организацию, считая итерационную работу и обучение на поставке чем-то само собой разумеющимся.
Зачем вообще Agile, если Waterfall и бюрократия не умерли
Generated by Nano Banana
Если отбросить лозунги, Agile нужен не для того, чтобы «всем было весело на стендапах». Он про другое: как дешевле учиться на реальности, когда окружение меняется быстрее наших планов.
Бюрократия и классический проектный подход решают задачу предсказуемости: чтобы люди знали свои роли, процессы повторялись, а результат можно было встроить в годовой план. В мире, где изменения редкие и медленные, этого достаточно.
Проблема начинается там, где:
требования двигаются вместе с рынком и технологиями,
цена задержки становится выше, чем цена возможных переделок, а «идеальное ТЗ» устаревает быстрее, чем его успевают согласовать.
Agile в такой среде меняет точку оптимизации:
вместо «минимизировать переделки» — минимизировать задержку обучения на ошибках,
вместо «сделать один большой правильный выстрел» — провести короткую разведку боем,
вместо «дотянуть любой ценой до финального релиза» — иметь право остановиться раньше, когда ценности уже достаточно или направление оказалось тупиковым.
Отсюда и вся остальная механика: инкременты, экспериментальность, короткие циклы. Не потому что так написано в книжке по Scrum, а потому что это дешёвый способ регулярно задавать себе два простых вопроса:
*«Мы всё ещё делаем то, что нужно?» и «Не пора ли остановиться или повернуть?»
А как же оптимизация? В такой формулировке Agile действительно не выглядит «идеально вылизанным»: лишние инкременты, разведка боем, работа над ошибками. Возможно, в моменте так и есть — по локальным затратам классический водопад иногда выглядит выгоднее. Но всё поддаётся сравнению на длинной дистанции. Гипотетически проект можно провести по Waterfall достаточно быстро, возможно даже быстрее, чем по Agile… вопрос только в том, принесёт ли он пользу в той реальности, в которую придёт через год. Как говорится, большое видится на расстоянии* на коротком отрезке мы экономим на «лишних» итерациях, на длинном — часто расплачиваемся за это годами поддержки не того решения.
От идеи до GA: знакомый Agile, который мы не всегда замечаем
Generated by Nano Banana
Если оглянуться назад на классический путь фичи или инициативы — Idea → Prototype → PoC → MVP → Pilot → GA — становится видно, что это по сути тоже конфигурация Agile.
Во-первых, каждый этап даёт **ощутимый инкремент**, пусть и не всегда в продакшене.
💡Идея оформлена и проговорена — уже инкремент по сравнению с неоформленным хаосом.
🧠 Прототип позволяет «пощупать» UX.
⚙️ PPoC проверяет техническую реализуемость.
👥 MVP — это уже рабочий продукт для ограниченной аудитории.
💼 Пилот даёт реальный опыт эксплуатации.
Каждый из этих шагов можно показать, обсудить, на нём можно учиться.
Во-вторых, такой workflow даёт возможность «съехать» на любой стадии с минимальными потерями. Если что-то не взлетает на уровне прототипа или PoC, мы теряем существенно меньше, чем если бы сразу шли к большому релизу. Это и есть та самая управляемая гибкость: мы не обязаны бежать до GA любой ценой, у нас есть несколько точек выхода по дороге.
Более того, в Agile совершенно нормально начать с одной идеи, а реализовать в итоге другую — и это не провал, а признак здорового процесса обучения. Об этом я расскажу в следующей статье.
Юрий Сергеевич Осипов — советский и российский математик, академик РАН, специалист в области теории управления, дифференциальных уравнений и их приложений. Президент Российской академии наук в 1991-2013 годах.
Область науки Вклад Значение
Теория управления Разработка теории позиционного управления и дифференциальных игр Создание новых методов управления сложными динамическими системами
Дифференциальные уравнения Исследования устойчивости решений дифференциальных уравнений Развитие качественной теории дифференциальных уравнений
Обратные задачи Разработка методов решения обратных задач динамики Создание основ для идентификации параметров сложных систем
Математическая теория устойчивости Исследования устойчивости по Ляпунову и её обобщений Развитие методов анализа устойчивости динамических систем
Прикладная математика Применение математических методов в механике и технике Решение практических задач управления и стабилизации
Ключевые научные достижения
Теория позиционного управления
Разработал теорию позиционного управления динамическими системами, которая позволяет строить алгоритмы управления в условиях неполной информации о состоянии системы.
Дифференциальные игры
Внес фундаментальный вклад в теорию дифференциальных игр, разработав методы решения задач преследования и уклонения для сложных динамических систем.
Обратные задачи динамики
Создал новые подходы к решению обратных задач динамики, позволяющие восстанавливать параметры системы по наблюдаемому движению.
Устойчивость динамических систем
Развил теорию устойчивости нелинейных систем, предложив новые критерии устойчивости и методы их анализа.
Научное направление Основные результаты Годы
Теория управления Разработка принципа позиционного управления с обратной связью 1970-1980
Дифференциальные игры Создание методов решения задач группового преследования 1980-1990
Обратные задачи Разработка алгоритмов идентификации параметров динамических систем 1990-2000
Устойчивость Обобщение методов Ляпунова для нелинейных систем 2000-2010
Прикладные задачи Применение теоретических результатов в технических системах 1970-настоящее время
Научно-организационная деятельность
Период Должность Вклад
1991-2013 Президент Российской академии наук Руководство крупнейшей научной организацией страны в переходный период
1986-1993 Директор Института математики и механики УрО РАН Развитие математической школы на Урале
1993-2013 Академик-секретарь Отделения математики РАН Координация математических исследований в России
2002-2013 Президент Международного математического союза Развитие международного сотрудничества в области математики
1991-2013 Главный редактор журнала "Известия РАН. Серия математическая" Руководство ведущим математическим журналом России
"Математика — это не только язык науки, но и мощный инструмент познания мира. Без развития математики невозможно развитие других наук и технологий."
— Юрий Осипов
Основные этапы научной деятельности
1959
Окончание Уральского государственного университета, начало научной работы в области дифференциальных уравнений
1965
Защита кандидатской диссертации по теории устойчивости дифференциальных уравнений
1971
Защита докторской диссертации по теории управления динамическими системами
1975
Назначение заведующим отделом теории управления в Институте математики и механики УрО РАН
1984
Избрание членом-корреспондентом АН СССР
1987
Избрание академиком АН СССР
1991
Избрание президентом Российской академии наук
2002
Избрание президентом Международного математического союза
Научное наследие и признание
Форма признанияОписаниеГосударственные наградыОрден "За заслуги перед Отечеством" I, II, III и IV степеней, Орден Ленина, Орден Октябрьской РеволюцииНаучные премииПремия имени А.М. Ляпунова РАН, Государственная премия РФ в области науки и техникиЧленство в академияхАкадемик РАН (1987), член-корреспондент с 1984 года, иностранный член многих зарубежных академийНаучные публикацииБолее 200 научных работ, включая монографии и учебные пособияПамятьПремия имени Ю.С. Осипова для молодых ученых, именные стипендииНаучная школаСоздал одну из ведущих российских школ теории управления и дифференциальных уравнений
"Юрий Сергеевич Осипов — это не только выдающийся математик, но и блестящий организатор науки, сумевший сохранить российскую академическую науку в сложнейшие годы."
— Академик Владимир Фортов
Фундаментальные научные концепции
Позиционное управление
Разработал теорию управления по принципу обратной связи, когда управляющие воздействия формируются на основе текущей информации о состоянии системы.
Метод программных итераций
Создал метод последовательных приближений для решения задач оптимального управления, позволяющий находить решения сложных нелинейных задач.
Теория дифференциальных игр
Развил математический аппарат для анализа конфликтно управляемых систем, когда несколько участников имеют противоположные цели.
Устойчивость нелинейных систем
Предложил новые критерии устойчивости для нелинейных динамических систем, обобщающие классические методы Ляпунова.
Вклад в развитие мировой науки
НаправлениеВклад ОсиповаМировое значениеТеория управленияРазработка принципов позиционного управления и методов обратной связиСоздание основ современных систем автоматического управленияДифференциальные игрыРазвитие математической теории конфликтно управляемых системПрименение в экономике, экологии, военном делеМатематическое образованиеПодготовка научных кадров, руководство математическими школамиСохранение и развитие математических традиций в РоссииМеждународное сотрудничествоРазвитие связей российской науки с мировым научным сообществомИнтеграция российской науки в мировое научное пространствоОрганизация наукиРуководство РАН в переходный период, сохранение научного потенциалаСохранение одной из ведущих научных школ мира
"Работы Юрия Сергеевича Осипова по теории управления и дифференциальным играм стали классическими и вошли в учебники по всему миру."
— Математик Джон Бэлл
Основные научные публикации
Название работыГодОбластьЗначение"Позиционные дифференциальные игры"1973Теория игрФундаментальная монография по теории дифференциальных игр"Обратные задачи динамики"1985Теория управленияСистематическое изложение методов решения обратных задач"Управление в условиях неопределенности"1992Теория управленияРазработка методов управления при неполной информации"Стабилизация нелинейных систем"2001Теория устойчивостиНовые подходы к анализу устойчивости сложных систем"Избранные труды по теории управления"2009Теория управленияСборник ключевых работ по различным аспектам теории управления
Информация о вкладе Юрия Сергеевича Осипова в мировую науку
