Табличку сравнительную сделаете? «Процессный подход» versus «Вне процессное управление»?
Нет. В рамках этой статьи такое сравнение не предполагалось. Я решил описать только узкую область, связанную с бизнес-процессами, реально исполняемыми в компьютерной среде предприятия.
Если интернет умалчивает о чем то (расчет эффективности внедрения) на протяжении десятилетий (BPM скорее стар, чем молод, а число его внедрений огромно), а эти тайные знания рассказывают только на семинаре некой Ассоциации, то возникает ассоциация с сектантством. Можете дать ссылку или рассказ про «выигрыш от внедрения»?
Число внедрений пока не очень большое, но они есть. Доклады о внедрениях публикуют в интернете очень неохотно, т.к. рассказ о своих бизнес-процессах может объяснить конкурентам компании, как в компании устроен бизнес.
Поэтому на мероприятиях ассоциации BPM-профессионалов принято для обсуждения кейсов внедрений, как правило, встречаться лично.
Но кое-что в интернете все-таки публикуют. Например, — Доклад от 18 июня 2015 г.
В статьях про «BPM: как все запущено и запутано» говорилось что часто «лавры победы» образуются только потому, что что-то автоматизировали. И не важно как: с помощью С+++ или с помощью...
Особенностью BPMS является то, что схема бизнес-процесса не является независимой от кода картинкой. Программисты часто «доделывают» бизнес-процесс: кодируют сложные алгоритмы в условиях выбора перехода, пишут коннекторы к другим системам, разрабатывают графические интерфейсы для форм задний и т.п.
Но точки управления при этом движутся только по отображаемой пользователю схеме бизнес-процесса. Они не могут «существенно разойтись» с программным кодом. Это помогает управленцам лучше понимать что происходит на предприятии.
Процессный офис и «процессный подход»
Что, по-вашему, делает «Процессный офис» в подобном представлении «процессного подхода»?
«Процессный офис» — это отдельная большая тема. В рамках данной статьи я ее не рассматриваю. «Процессный офис» подробно описан, например, здесь.
Как такая «процессная команда» реализуют Ваш «процессный подход»?
В частности, там есть понятное разделение труда: управленцы «заказывают» программистам нужные им элементы. Далее из этих элементов собирается нужная управленцам конструкция.
Главный вопрос: прочитать бы где-нибудь — Как внедрили этот самый Процессный подход и как посчитали выигрыш от внедрения.
Доклады о реальных внедрениях процессного подхода проводятся, например, Ассоциацией BPM-профессионалов. Эти мероприятия свободные, участвовать могут все желающие:
Может быть, ответ очевиден для программистов, но для меня текущие результаты верхнего опроса (программистов) оказались неожиданными. В частности, я предполагал, что процент ответа «Оклад с бонусами и штрафами» будет ниже.
Топикстартер ведь чётко обозначил, что работает с фрилансерами, а они практически всегда ИП (если работают «вбелую», конечно).
Я работаю с фрилансерами, но не только с фрилансерами. В частности, в компании есть штатные удаленные сотрудники.
У нас есть фрилансеры, которые ИП, но таких меньше половины. С большей частью фрилансеров я заключаю гражданско-правовые договора.
Лично мне еще не довелось работать в таких местах, где платили бы за переработку...
Если договором предусмотрено, что зарплата программиста пропорциональна затраченному времени, то понятие «переработка» исчезает. Сколько часов отработал программист, — такая и зарплата. При удаленной работе это часто происходит.
Э, нее. За bus factor отвечает руководитель программиста, а не сам программист. Если над сложным модулем работает только один программист, то это косяк его начальника.
В данном случае имеется в виду не потеря знаний о системе, а уменьшение команды. — Если кто-то проект покидает, то оставшиеся разработчики уже не могут выполнять такой же объем работы, особенно если им еще надо кого-то обучать. Поэтому сотрудник перед уходом может постепенно «вводить в курс дела» кого-то из новых разработчиков. В сложном проекте от нового разработчика может потребоваться длительное время, чтобы в нем разобраться.
Если, как сам топикстартер пишет, проекты настолько уникальны, что на них нет среднерыночной цены...
Не сами проекты, а задачи в проекте бывают уникальны. Например, в процессе выполнения требуется проанализировать несколько технологий и выбрать из них лучшую для конкретной ситуации и т.п.
человек писал ведь, что он изобрёл быстрый способ решения некоего класса задач, но намеренно затягивал сроки вдвое,
Код, отправленный в репозиторий, анализирует на качество кода ведущий разработчик. Ведущий разработчик знает выставленную программистом трудоемкость по задаче и видит его код. — В случае длительного сотрудничества становится понятно, кто как работает.
Если фрилансер «подсаживается» на длительный проект, отнимающий значительное количество его рабочего времени — он тем самым превращается в обычного удалёнщика
Так часто происходит в наших проектах. — Мы начинаем взаимодействовать с фрилансером, а через некоторое время он становится практически удаленным сотрудником.
На долгосрочные проекты выгоднее держать программистов в штате (возможно — удалённых), нежели пользоваться услугами фрилансеров.
В моей практике есть примеры длительной работы как штатных удаленных программистов, так и внештатных. Почему в случае долгосрочных проектов использование фрилансеров должно быть менее выгодно?
Мой подход — не увязывать напрямую зарплату специалиста с тем, какую пользу он приносит компании. Я стараюсь набирать людей, которым интересен проект. А зарплата должна быть такой, чтобы у сотрудник мог нормально жить, не задумываясь о пропитании, и сосредоточиться на задаче.
Я думаю вы тут неудачно мысль сформулировали. Речь ведь идёт про «нормально жить» по критерию работника, а не по вашему? Для какого-то абстрактного программиста в вакууме «нормально» — это иметь возможность откладывать по 100 тыр в месяц на старость и питаться только в ресторанах. Вы примете такую норму?
Часовая ставка сотрудника может определяться рынком. То есть, в целом примерно соответствовать доходу, который программист такой же квалификации мог бы получать в других компаниях.
Конкретные работы программиста я оцениваю через эту ставку и реально затраченное время.
В сложных проектах это не получается. Однако, если программист увлечен проектом, но по каким-то причинам ему надо уйти, то он может заранее постепенно «передать» свои задачи другим сотрудникам и/или помогать и консультировать их, работая уже в другом месте.
оплачивая работу людям из количества часов, Вы начинаете игру в одни ворота…
… получается изначально вырожденный вариант: Вы платите больше денег за то, что получаете решение задачи позже. То есть программисту оказывается выгодно затягивать решение вопроса
Я стараюсь найти разработчиков, для которых целью является не «получить максимально возможную сумму денег», а «сделать хорошую вещь», получая при этом нормальные деньги.
Простите, Вам от разработчика нужны просиженные перед компьютером часы? Строчки кода «в количестве не менее»? Или всё-таки решение поставленной задачи?
Базовая стоимость определяется рынком.
Если задачи сложные, то их трудоемкость заранее трудно оценить. Ошибка оценки большая. Рынок здесь не поможет, т.к. сравнить не с чем. Если оценка таких работ в среднем будет заметно заниженная, то доход программиста по сравнению с работой в офисе будет существенно меньше и программист, скорее всего, через некоторое время откажется от задач по этому проекту. Что будет плохо для работодателя, т.к. придется искать нового программиста, ждать, когда он войдет в тему и т.п. Если оценка работ в среднем будет завышена, то вариант оплаты работ по заранее согласованной сумме тоже будет плохим для работодателя, т.к. приведет к высоким затратам.
Если программист нормальный, то оплата по фактически затраченному времени оказывается удобна и для него (стабильность выше, доход предсказуем) и для работодателя.
Т.е. предусматривается только вариант прекращения сотрудничества, но не повышения или понижения зарплаты в зависимости от эффективности.
Ставка может повышаться. Но она зависит не от конкретно выполненной работы, а от косвенных характеристик. Например. — Разработчик разобрался в ядре системы и может выполнять соответствующие сложные работы. Разработчик может ставить задачу группе программистов из 3-5 человек и т.п. Для каждого вида деятельности применяется своя ставка. Для сложных видов деятельности ставка существенно выше.
Если оклад зависит от часов — люди будут спать, заниматься своими личными делами и т. п. на работе.
Почему-то в моей практике такого не было. Возможно, потому что я стараюсь искать людей творческих и давать им интересные задачи.
По факту штраф — это обида сотрудника на компанию, т.к. в большинстве случаев сотрудник себя виноватым не считает. Плюс снижается его уверенность в завтрашнем дне.
Я тоже так считаю и штрафы в своей деятельности никогда не использую. Однако, есть компании, которые пишут, что у них программисты так работают (с бонусами и штрафами), при этом коллектив стабильный. (Ссылка на публикацию).
Что считать затраченным временем? Сидение у компьютера? Набор кода? Наброски архитектуры карандашом на бумаге? Сидеть на толчке и обдумывать реализацию фичи и применяемые в ней алгоритмы?
В моей практике — это решает сам разработчик. Разработчик посылает мне отчет по работам. Если я давно с этим программистом работаю, то, как правило, сразу оплачиваю присланное количество часов по оговоренной ставке. Иногда, если плановое время сильно превышено, прошу написать, что случилось, что не учли изначально и т.п.
> А где вариант «Я плачу\получаю деньги за решение конкретных задач с заданным качеством»…
Как платятся деньги, если код написан, а качество недостаточное? Это трудно учесть в опросе.
(Я в таком случае отправляю задачу на доработку и оплачиваю общее время по задаче после ее успешного завершения)
Если в эксплуатации проявилась ошибка в коде коннектора, обработчика или в логике бизнес-процесса, — это может вызвать проблемы.
Если ошибка в логике, — бизнес-аналитик ее исправляет и передает администратору BPMS новую версию бизнес-процесса для загрузки в систему. После установки новой версии, новые экземпляры данного бизнес-процесса уже будут нормально исполняться, но надо еще исправить старые экземпляры. Для этого применяются различные варианты действий:
Бизнес-аналитик пишет администратору BPMS заявку, в которой описывает, в каких экземплярах бизнес-процессов надо изменить переменные и указывает их правильные значения. Иногда этого достаточно, чтобы процессы пошли дальше
Бизнес-аналитик разрабатывает специальную (корректирующую) версию бизнес-процесса, содержащую элементы, исправляющие логические ошибки в «зависших» процессах. Администратор загружает корректирующую версию бизнес-процесса в BPMS и обновляет на нее соответствующие экземпляры. При обновлении экземпляр заменяется на новый, в котором новая схема и переменные, точки управления автоматически переносятся со старой схемы на новую, значения старых переменных передаются в новые переменные. После этого обновленные экземпляры выполняются до завершения
В сложных случаях часто помогает:
Запустить для экземпляра бизнес-процесса бизнес-процесс его полной отмены
Запустить отмененный бизнес-процесс заново, но уже для исправленной версии определения бизнес-процесса
Если ошибка в коде, то программист исправляет ее, собирает новый компонент и пишет заявку администратору BPMS на обновление компонента в системе. Иногда загрузки нового компонента достаточно, чтобы «зависшие» экземпляры пошли дальше. Если нет, то можно дополнительно применить описанные выше варианты действий.
При эксплуатации BPMS важно, чтобы программист и бизнес-аналитик работали с промышленной системой не напрямую, а через администратора, а также чтобы все корректирующие действия фиксировались и оформлялись соответствующими документами.
Иначе можно потерять контроль над системой — никто не будет понимать, почему система себя так ведет, надежны ли содержащиеся в ней данные и как можно исправить ошибки…
Понятно, что откаты нужно отдельно программировать. Минимально, что можно сделать автоматически, это запустить процесс с прежней точки и попросить пользователей подтвердить свое прежнее решение.
Не совсем понятно, что делать, если кто-то не подтвердит свое прежнее решение.
Число внедрений пока не очень большое, но они есть. Доклады о внедрениях публикуют в интернете очень неохотно, т.к. рассказ о своих бизнес-процессах может объяснить конкурентам компании, как в компании устроен бизнес.
Поэтому на мероприятиях ассоциации BPM-профессионалов принято для обсуждения кейсов внедрений, как правило, встречаться лично.
Но кое-что в интернете все-таки публикуют. Например, — Доклад от 18 июня 2015 г.
Особенностью BPMS является то, что схема бизнес-процесса не является независимой от кода картинкой. Программисты часто «доделывают» бизнес-процесс: кодируют сложные алгоритмы в условиях выбора перехода, пишут коннекторы к другим системам, разрабатывают графические интерфейсы для форм задний и т.п.
Но точки управления при этом движутся только по отображаемой пользователю схеме бизнес-процесса. Они не могут «существенно разойтись» с программным кодом. Это помогает управленцам лучше понимать что происходит на предприятии.
«Процессный офис» — это отдельная большая тема. В рамках данной статьи я ее не рассматриваю. «Процессный офис» подробно описан, например, здесь.
В частности, там есть понятное разделение труда: управленцы «заказывают» программистам нужные им элементы. Далее из этих элементов собирается нужная управленцам конструкция.
У нас есть фрилансеры, которые ИП, но таких меньше половины. С большей частью фрилансеров я заключаю гражданско-правовые договора.
Код, отправленный в репозиторий, анализирует на качество кода ведущий разработчик. Ведущий разработчик знает выставленную программистом трудоемкость по задаче и видит его код. — В случае длительного сотрудничества становится понятно, кто как работает.
25 человек
Конкретные работы программиста я оцениваю через эту ставку и реально затраченное время.
В сложных проектах это не получается. Однако, если программист увлечен проектом, но по каким-то причинам ему надо уйти, то он может заранее постепенно «передать» свои задачи другим сотрудникам и/или помогать и консультировать их, работая уже в другом месте.
Я стараюсь найти разработчиков, для которых целью является не «получить максимально возможную сумму денег», а «сделать хорошую вещь», получая при этом нормальные деньги.
Если задачи сложные, то их трудоемкость заранее трудно оценить. Ошибка оценки большая. Рынок здесь не поможет, т.к. сравнить не с чем. Если оценка таких работ в среднем будет заметно заниженная, то доход программиста по сравнению с работой в офисе будет существенно меньше и программист, скорее всего, через некоторое время откажется от задач по этому проекту. Что будет плохо для работодателя, т.к. придется искать нового программиста, ждать, когда он войдет в тему и т.п. Если оценка работ в среднем будет завышена, то вариант оплаты работ по заранее согласованной сумме тоже будет плохим для работодателя, т.к. приведет к высоким затратам.
Если программист нормальный, то оплата по фактически затраченному времени оказывается удобна и для него (стабильность выше, доход предсказуем) и для работодателя.
Ставка может повышаться. Но она зависит не от конкретно выполненной работы, а от косвенных характеристик. Например. — Разработчик разобрался в ядре системы и может выполнять соответствующие сложные работы. Разработчик может ставить задачу группе программистов из 3-5 человек и т.п. Для каждого вида деятельности применяется своя ставка. Для сложных видов деятельности ставка существенно выше.
Почему-то в моей практике такого не было. Возможно, потому что я стараюсь искать людей творческих и давать им интересные задачи.
Я тоже так считаю и штрафы в своей деятельности никогда не использую. Однако, есть компании, которые пишут, что у них программисты так работают (с бонусами и штрафами), при этом коллектив стабильный. (Ссылка на публикацию).
В моей практике — это решает сам разработчик. Разработчик посылает мне отчет по работам. Если я давно с этим программистом работаю, то, как правило, сразу оплачиваю присланное количество часов по оговоренной ставке. Иногда, если плановое время сильно превышено, прошу написать, что случилось, что не учли изначально и т.п.
Как платятся деньги, если код написан, а качество недостаточное? Это трудно учесть в опросе.
(Я в таком случае отправляю задачу на доработку и оплачиваю общее время по задаче после ее успешного завершения)
Если ошибка в логике, — бизнес-аналитик ее исправляет и передает администратору BPMS новую версию бизнес-процесса для загрузки в систему. После установки новой версии, новые экземпляры данного бизнес-процесса уже будут нормально исполняться, но надо еще исправить старые экземпляры. Для этого применяются различные варианты действий:
Если ошибка в коде, то программист исправляет ее, собирает новый компонент и пишет заявку администратору BPMS на обновление компонента в системе. Иногда загрузки нового компонента достаточно, чтобы «зависшие» экземпляры пошли дальше. Если нет, то можно дополнительно применить описанные выше варианты действий.
При эксплуатации BPMS важно, чтобы программист и бизнес-аналитик работали с промышленной системой не напрямую, а через администратора, а также чтобы все корректирующие действия фиксировались и оформлялись соответствующими документами.
Иначе можно потерять контроль над системой — никто не будет понимать, почему система себя так ведет, надежны ли содержащиеся в ней данные и как можно исправить ошибки…
Не совсем понятно, что делать, если кто-то не подтвердит свое прежнее решение.