Количество строк кода — если выбирается в качестве KPI, то программисты просто учатся разносить аргументы методов и скобочки по разным строкам, а потом и вовсе начинают писать откровенно ненужный код.
Я помню, как после сдачи проекта по бухгалтерии, появилось время, чтобы все сделать правильно. Всю сложную логику, которая считала деньги выделили в отдельные функции, которые начали использовать во всех режимах программы.
Ушли мерзкие ошибки, когда в разных отчетах и разрезах не бились итоговые суммы на одну или несколько копеек — страх и трепет любого бухгалтера. Появилась возможность добавления «особых условий» для разных ситуаций. НО! Количество строк кода уменьшилось на несколько тысяч. Таким образом, по данному KPI, я нанес огромный ущерб компании :).
Хорошо руководитель был в теме IT. Посчитали, сколько с меня сняли с учетом этого KPI, после чего выписали персональную премию в двойном размере…
Добавлю еще одну потенциальную мину разработки игр — готовый инструментарий к неготовой игре. Это актуально не для всех игр, но если все таки актуально, то многие на него попадаются…
В какой-то момент разработки Вы поймете, что Вам нужно либо создавать библиотеку контента, либо генерировать его случайным образом.
Создавать библиотеку вручную довольно муторно, кроме того во многих случаях генерация случайного контента является несомненным плюсом игры, поэтому Вы говорите себе: «Я сейчас сделаю генератор и потом буду использовать его в игре, и это будет хорошо!».
После какого-то времени разработки этого у Вас получается отличный генератор, но сил на саму игру уже не хватает… Даже если сил хватает, то неготовая игра еще «дышит» и может значительно меняться — это нормально. Но у Вас уже есть готовый инструментарий, который необходимо поддерживать, чтобы он соответствовал изменениям игры. И силы уходят не туда…
Правильно делать игру с MIN контента и лишь на финальной стадии делать инструментарий…
Мне кажется описанный выше подход (с точки зрения учета) спорным. По факту есть 2 основных подхода — с точки зрения бизнеса (которому надо результат), и с точки зрения реализации (которой надо этот результат обеспечить). В обоих случаях нужно прыгать именно вокруг потока задач на получение этого результата, и только потом на том, кто и как эти задачи будет выполнять…
Бизнес процессы — это и есть процессы, ориентированные на результат, в которые входит в том числе и учет всех нюансов, посредством артефакта «Карточка процесса». НО, относящихся ТОЛЬКО к самому процессу. В ней не место, например, образованию исполнителя N шага процесса, да и часто, самому исполнителю. Если кто-то заболел, изменилось штатное расписание — процесс ведь не поменяется…
Что же касается реализации, то бизнес процессы могут быть реализованы очень разными путями, и через отдельный процесс, и через унифицированные процессы. Учет здесь лучше всего вести с помощью документов или физического «результата». Расскажите историю документа (детали) от «я родился» до «получил статус „Done“ (прошел проверку качества)»…
Какое обоснование преимущества универсальной CRM перед узкоспециализированным софтом?
Если бизнес не состоит из одной формы и пары отчетов, то преимуществ может быть очень много, например:
Готовые (обновляемые) отчеты для предоставления регулирующим органам
Готовые адаптеры для импорта и экспорта данных в другое ПО
Обеспечение требований по безопасности, производительности и т.п.
Наличие готовых специалистов или готовность работников изучать это ПО для повышения своих компетенций (не будет такого, что человек, который является экспертом в доморощенной программе, при смене работы будет себя чувствовать как рыба на суше)
Нет доверия к таким градусникам — мерили температуру ребенку несколько раз водя по 2-3 сек — показывал температуру 37.5, померили ртутным — 39+. Разница в 1.5+ градуса очень существенна.
Самое фиговое в том, что вместо принятия срочных мер можно "успокоиться" "немного" повышенной температурой с очень печальными последствиями…
К сожалению, когда дело доходит до покупки, внезапно выясняется, что в действительности выбор очень сильно меньше, чем казалось вначале…
А из того, что осталось половина имеет совершенно невменяемые сроки поставки как самих серверов, так и их комплектующих при необходимости замены.
Отдельно доставляет цена серверов, которую поставщики сразу не озвучивают и которая зависит от того, на сколько «жирным» потенциальным клиентом Вы являетесь…
Вообще-то не планировал, т.к. не вижу в этом чьей-либо потребности…
Однако, если Вы, например, хотите попробовать визуализировать то, что на картинке как-то по другому, то могу либо выслать несколько наборов, либо доделать и выложить генератор, чтобы каждый мог генерировать себе столько Галактик, сколько захочет…
Никто не мешает Вам на отлично зарекомендовавший себя скелет навешивать столько фарша, сколько Вам нужно, расширяя и дополняя то, что есть, тем, чего не хватает!
Вопрос разработки документации по ГОСТ больше в том — на сколько полной должна быть формализация проекта и хватит ли на это ресурсов?
kurtan — старая (еще с времен DOS) добрая головоломка, неоднократно копировалась и переиздавалась…
Legend of Grimrock — внутри есть множество различных головоломок.
Унифицированный процесс — это процесс относящийся к группе процессов, характеризуемых схожим сценарием обработки и взаимодействия. Унифицированные процессы являются готовыми блоками, которые можно многократно использовать в технологических/бизнес процессах, тем самым удешевляя разработку и уменьшая количество ошибок.
Примеры:
1)
Для проверки объекта учета (под объектом учета может быть все, что угодно — человек, товар, описанный в виде документа или группы документов), перед его сохранением в БД нужно выполнить некоторые стандартные шаги:
Предположим, что мы получаем какие-то данные для сохранения в БД (не важно — наши эти данные или мы получили их со стороны) и предположим, что таких объектов учета у нас 100500. Тогда в УП (унифицированном процессе) «Проверка объекта учета» первым будет следующий шаг:
— обращение к ODM движку для получения списка шагов проверки (проверка ЭЦП, xlt преобразование, ФЛК, сравнение атрибутов нескольких документов между собой, когда есть список документов и опись, проверка документа по сервисам, какой-то ответ-квитанция отправителю и т.д.).
— далее — шаги по каждому типу проверки. Сразу обращаю внимание, Flow один и состоит из всех возможных шагов, те из них, которые неактуальны для какого-то объекта учета, считаются NULL.
— Далее выполняются только актуальные шаги УП.
Что дает УП:
— один унифицированный Flow — при добавлении нового объекта учета здесь ничего не меняется.
— вся логика в ODM — при добавлении нового объекта учета просто добавляем для него новую запись в таблицы.
— при каких-либо изменениях (например, СМЭВ новый регламент выпустил и теперь квитанцию туда с дополнительными атрибутами нужно отправлять), Вы имеете одну точку, требующую изменения, которая покроет все бизнес процессы. Если у Вас 100500 объектов учета, это архиважно.
2)
На выходе из процесса «Проверка объекта учета» мы получаем либо ОК/Не ОК, либо квитанцию, в которой написано ОК/Не ОК + список ошибок, если они были. Для самой квитанции может быть нужно выполнить преобразование, обогащение, добавление ЭЦП и маршрутизацию N контрагентам. Это тема еще одного УП.
> Если BPMN движки, хоть как то стандартизированы, то ODM движки (BRM) — нет. Не будет ли такой «вынос логики» шагом назад?
Нет — Вы будете использовать этот ODM движок в качестве сервиса. По сути Вы сложное разбиваете на 2 части попроще, а это хорошо. В высоконагруженной системе Вы еще получаете возможность вынести часть нагрузки с BPMN движка на сторону — и это опять хорошо.
>Про «унификацию бизнес-процессов» — Вы это серьезно? В современной капиталистической России?
>Для унификации требуются, как минимум, соответствующая инфраструктура и реинжиниринг стереотипов «владельцев процессов».
Серьезно, ибо сам этим занимаюсь. Относитесь к унифицированным процессам как к сервисам, которые реализуют часть востребованного всеми функционала. Понятно, что за этим «базовым» набором процессов должен быть повышенный контроль, что они должны быть специфицированы и доведены до конечного потребителя (разработчиков процессов).
Когда появляется новый большой процесс 4/5 которого уже «живет» в виде унифицированных процессов + пары табличек в ODM, реализовывать его гораздо веселей… При этом не нужно делать регрессионное тестирование, потому, что старое Вы нигде не затронули. А если таких процессов несколько десятков…
[0..n]
[0..1]
choice [0..1]
…
Я помню, как после сдачи проекта по бухгалтерии, появилось время, чтобы все сделать правильно. Всю сложную логику, которая считала деньги выделили в отдельные функции, которые начали использовать во всех режимах программы.
Ушли мерзкие ошибки, когда в разных отчетах и разрезах не бились итоговые суммы на одну или несколько копеек — страх и трепет любого бухгалтера. Появилась возможность добавления «особых условий» для разных ситуаций. НО! Количество строк кода уменьшилось на несколько тысяч. Таким образом, по данному KPI, я нанес огромный ущерб компании :).
Хорошо руководитель был в теме IT. Посчитали, сколько с меня сняли с учетом этого KPI, после чего выписали персональную премию в двойном размере…
В какой-то момент разработки Вы поймете, что Вам нужно либо создавать библиотеку контента, либо генерировать его случайным образом.
Создавать библиотеку вручную довольно муторно, кроме того во многих случаях генерация случайного контента является несомненным плюсом игры, поэтому Вы говорите себе: «Я сейчас сделаю генератор и потом буду использовать его в игре, и это будет хорошо!».
После какого-то времени разработки этого у Вас получается отличный генератор, но сил на саму игру уже не хватает… Даже если сил хватает, то неготовая игра еще «дышит» и может значительно меняться — это нормально. Но у Вас уже есть готовый инструментарий, который необходимо поддерживать, чтобы он соответствовал изменениям игры. И силы уходят не туда…
Правильно делать игру с MIN контента и лишь на финальной стадии делать инструментарий…
Зачем понятное заменять более непонятным?
Мне кажется описанный выше подход (с точки зрения учета) спорным. По факту есть 2 основных подхода — с точки зрения бизнеса (которому надо результат), и с точки зрения реализации (которой надо этот результат обеспечить). В обоих случаях нужно прыгать именно вокруг потока задач на получение этого результата, и только потом на том, кто и как эти задачи будет выполнять…
Бизнес процессы — это и есть процессы, ориентированные на результат, в которые входит в том числе и учет всех нюансов, посредством артефакта «Карточка процесса». НО, относящихся ТОЛЬКО к самому процессу. В ней не место, например, образованию исполнителя N шага процесса, да и часто, самому исполнителю. Если кто-то заболел, изменилось штатное расписание — процесс ведь не поменяется…
Что же касается реализации, то бизнес процессы могут быть реализованы очень разными путями, и через отдельный процесс, и через унифицированные процессы. Учет здесь лучше всего вести с помощью документов или физического «результата». Расскажите историю документа (детали) от «я родился» до «получил статус „Done“ (прошел проверку качества)»…
Если бизнес не состоит из одной формы и пары отчетов, то преимуществ может быть очень много, например:
Нет доверия к таким градусникам — мерили температуру ребенку несколько раз водя по 2-3 сек — показывал температуру 37.5, померили ртутным — 39+. Разница в 1.5+ градуса очень существенна.
Самое фиговое в том, что вместо принятия срочных мер можно "успокоиться" "немного" повышенной температурой с очень печальными последствиями…
А из того, что осталось половина имеет совершенно невменяемые сроки поставки как самих серверов, так и их комплектующих при необходимости замены.
Отдельно доставляет цена серверов, которую поставщики сразу не озвучивают и которая зависит от того, на сколько «жирным» потенциальным клиентом Вы являетесь…
Однако, если Вы, например, хотите попробовать визуализировать то, что на картинке как-то по другому, то могу либо выслать несколько наборов, либо доделать и выложить генератор, чтобы каждый мог генерировать себе столько Галактик, сколько захочет…
Да ладно! Может Вы их просто готовить не умеете?
Никто не мешает Вам на отлично зарекомендовавший себя скелет навешивать столько фарша, сколько Вам нужно, расширяя и дополняя то, что есть, тем, чего не хватает!
Вопрос разработки документации по ГОСТ больше в том — на сколько полной должна быть формализация проекта и хватит ли на это ресурсов?
Добавлю еще:
kurtan — старая (еще с времен DOS) добрая головоломка, неоднократно копировалась и переиздавалась…
Legend of Grimrock — внутри есть множество различных головоломок.
Не могу ничего возразить по сути, но внутри такое чувство, что меня в чем-то обманывают.
Ну не могут два зрителя одновременно быть замедленными друг относительно друга...
https://www.youtube.com/watch?v=K2slWzooD2w
Примеры:
1)
Для проверки объекта учета (под объектом учета может быть все, что угодно — человек, товар, описанный в виде документа или группы документов), перед его сохранением в БД нужно выполнить некоторые стандартные шаги:
Предположим, что мы получаем какие-то данные для сохранения в БД (не важно — наши эти данные или мы получили их со стороны) и предположим, что таких объектов учета у нас 100500. Тогда в УП (унифицированном процессе) «Проверка объекта учета» первым будет следующий шаг:
— обращение к ODM движку для получения списка шагов проверки (проверка ЭЦП, xlt преобразование, ФЛК, сравнение атрибутов нескольких документов между собой, когда есть список документов и опись, проверка документа по сервисам, какой-то ответ-квитанция отправителю и т.д.).
— далее — шаги по каждому типу проверки. Сразу обращаю внимание, Flow один и состоит из всех возможных шагов, те из них, которые неактуальны для какого-то объекта учета, считаются NULL.
— Далее выполняются только актуальные шаги УП.
Что дает УП:
— один унифицированный Flow — при добавлении нового объекта учета здесь ничего не меняется.
— вся логика в ODM — при добавлении нового объекта учета просто добавляем для него новую запись в таблицы.
— при каких-либо изменениях (например, СМЭВ новый регламент выпустил и теперь квитанцию туда с дополнительными атрибутами нужно отправлять), Вы имеете одну точку, требующую изменения, которая покроет все бизнес процессы. Если у Вас 100500 объектов учета, это архиважно.
2)
На выходе из процесса «Проверка объекта учета» мы получаем либо ОК/Не ОК, либо квитанцию, в которой написано ОК/Не ОК + список ошибок, если они были. Для самой квитанции может быть нужно выполнить преобразование, обогащение, добавление ЭЦП и маршрутизацию N контрагентам. Это тема еще одного УП.
Нет — Вы будете использовать этот ODM движок в качестве сервиса. По сути Вы сложное разбиваете на 2 части попроще, а это хорошо. В высоконагруженной системе Вы еще получаете возможность вынести часть нагрузки с BPMN движка на сторону — и это опять хорошо.
>Про «унификацию бизнес-процессов» — Вы это серьезно? В современной капиталистической России?
>Для унификации требуются, как минимум, соответствующая инфраструктура и реинжиниринг стереотипов «владельцев процессов».
Серьезно, ибо сам этим занимаюсь. Относитесь к унифицированным процессам как к сервисам, которые реализуют часть востребованного всеми функционала. Понятно, что за этим «базовым» набором процессов должен быть повышенный контроль, что они должны быть специфицированы и доведены до конечного потребителя (разработчиков процессов).
Когда появляется новый большой процесс 4/5 которого уже «живет» в виде унифицированных процессов + пары табличек в ODM, реализовывать его гораздо веселей… При этом не нужно делать регрессионное тестирование, потому, что старое Вы нигде не затронули. А если таких процессов несколько десятков…