Ещё в 2005 году участвовал в разработке подобной системы. Называлась "Система поддержки принятия решений для моделирования процессов добычи нефти "Нефтепромысел"". Она позволяла следующее:
- Мониторинг и управление фондом скважин;
- Подбор оборудования и оптимизация режима;
- Диагностика геолого-технического состояния скважин;
- Расчёт индикаторной диаграммы;
- Анализ и оптимизация технологических, гидравлических, энергетических и технико-экономических показателей эксплуатации скважин;
- Визуализация и исследование истории параметров эксплуатации скважин;
- Расчёт потребности в оборудовании для цеха, предприятия;
- Расчёт эффективности намечаемых и проведённых мероприятий;
- Учёт движения оборудования.
Даже делали внедрение её в TNK-BP. Но по политическим причинам дело не пошло.
К сожалению, в сети уже не найти ссылки на её описание... :(
Спасибо всем откликнувшимся (в том числе в личке).
Хочу ответить на ваши комменты одним сообщением:
На счет способа изложения. Сложно предугадать как воспримят тот или иной контент разные люди. Не зная на сколько они погружены в терминологию и проблемы ИТ, я старался объяснить как можно понятнее. Это порождает большой объём. К тому же, указанное нельзя было оцифровать (предоставить показатели) по всему ИТ (по крайне мере в имеющееся время).
В письме топам, в кратком виде, указывались причины обращения и содержание приложенного документа. Всё остальное шло вложением.
Оценка трансформации, план, ресурсы и т.п. не делались, т.к. не была понятна позиция руководства по изложенному. К тому же, трансформация затронуло бы весь ИТ, а такое в одиночку просчитать и спланировать в крупных компаниях маловероятно. Если бы руководство выразило заинтересованность, то дальше пошли бы уточнения и согласования.
В качестве примера приведу анекдот: Нанял муж детектива, т.к. подозревал жену в измене. Детектив предоставил отчёт, в котором было указано, что его супруга встречалась в квартире с незнакомым мужчиной: Наблюдение в окно показало, что они пили вино, танцевали, потом разделись, легли в кровать, закрыли шторки. Дальнейшее наблюдение было невозможно по объективным причинам. Муж прочитав отчёт сказал: ну как всегда, никаких доказательств.
Т.е., по моему мнению, кто заинтересован увидеть проблемы, увидел бы их и не остался в стороне.
Судить о предложенном составе отдела, без знания объёма работ поддерживаемых систем, и составов других отделов, затруднительно. Поэтому оставлю коммент без ответа.
О связи пунктов. Я пытался представить их так:
текущая ситуация в отделе
выводы
предложения по отделу
предложения по всему ИТ
На счет демагогии. Демагогия, в моём понимании, должна базироваться на логических ошибках в тексте/речи. Какие логические ошибки здесь?
Т.е. проверкой реализованного у вас заняты аналитики, а не тестировщики? Почему так? И почему код-ревью идёт после проверки реализации? Не потребуется ли проводить повторное тестирование если код не пройдёт код-ревью?
Приветствую!@aimfirst, уточните, пожалуйста, как ваши разработчики определяют какую задачу надо брать в работу? По канбану (верхний таск)? Как боретесь с тем, что берут в работу не то что сверху? Не думали-ли вы над тем, чтобы в Jira сделать кнопку, которая будет "выдавать и сразу запускать" таск в работу? Чтобы разработчик не терял время на выбор таски и у него небыло соблазна взять таск "что по легче".
Приветствую! @aimfirst, уточните, пожалуйста, как в описанном вами процессе проходят стадии анализа (описание аналитиками что надо сделать) и кодревью?
В проект CartPay ищем питерского самоделкина для работы с железом за долю в проекте.
Задачи: выбор железа (микроконтроллеров/датчиков/...), их программирование, установка в тележку, модификация тележки.
Все вопросы на evgeny[at]cartpay.co.
Если передумал – поднял товар, отсканировал, положил на полку.
Для шапки/сумки будет отдельный ключёк не влияющий на весы. Кота, просьба, оставлять дома :)
Дело не только в цене меток, но и в оплате труда людей которые будут их клеить на товар, т.к. не всё можно автоматизировать.
Пока производитель сам не будет наносить метки на свой товар, маловероятно что ритейл будет сам их клеить.
Ещё в 2005 году участвовал в разработке подобной системы. Называлась "Система поддержки принятия решений для моделирования процессов добычи нефти "Нефтепромысел"". Она позволяла следующее:
- Мониторинг и управление фондом скважин;
- Подбор оборудования и оптимизация режима;
- Диагностика геолого-технического состояния скважин;
- Расчёт индикаторной диаграммы;
- Анализ и оптимизация технологических, гидравлических, энергетических и технико-экономических показателей эксплуатации скважин;
- Визуализация и исследование истории параметров эксплуатации скважин;
- Расчёт потребности в оборудовании для цеха, предприятия;
- Расчёт эффективности намечаемых и проведённых мероприятий;
- Учёт движения оборудования.
Даже делали внедрение её в TNK-BP. Но по политическим причинам дело не пошло.
К сожалению, в сети уже не найти ссылки на её описание... :(
Спасибо всем откликнувшимся (в том числе в личке).
Хочу ответить на ваши комменты одним сообщением:
На счет способа изложения. Сложно предугадать как воспримят тот или иной контент разные люди. Не зная на сколько они погружены в терминологию и проблемы ИТ, я старался объяснить как можно понятнее. Это порождает большой объём. К тому же, указанное нельзя было оцифровать (предоставить показатели) по всему ИТ (по крайне мере в имеющееся время).
В письме топам, в кратком виде, указывались причины обращения и содержание приложенного документа. Всё остальное шло вложением.
Оценка трансформации, план, ресурсы и т.п. не делались, т.к. не была понятна позиция руководства по изложенному. К тому же, трансформация затронуло бы весь ИТ, а такое в одиночку просчитать и спланировать в крупных компаниях маловероятно. Если бы руководство выразило заинтересованность, то дальше пошли бы уточнения и согласования.
В качестве примера приведу анекдот: Нанял муж детектива, т.к. подозревал жену в измене. Детектив предоставил отчёт, в котором было указано, что его супруга встречалась в квартире с незнакомым мужчиной: Наблюдение в окно показало, что они пили вино, танцевали, потом разделись, легли в кровать, закрыли шторки. Дальнейшее наблюдение было невозможно по объективным причинам. Муж прочитав отчёт сказал: ну как всегда, никаких доказательств.
Т.е., по моему мнению, кто заинтересован увидеть проблемы, увидел бы их и не остался в стороне.
Судить о предложенном составе отдела, без знания объёма работ поддерживаемых систем, и составов других отделов, затруднительно. Поэтому оставлю коммент без ответа.
О связи пунктов. Я пытался представить их так:
текущая ситуация в отделе
выводы
предложения по отделу
предложения по всему ИТ
На счет демагогии. Демагогия, в моём понимании, должна базироваться на логических ошибках в тексте/речи. Какие логические ошибки здесь?
Айтишников много, более 100.
И да, указанное в описании было как отдельный документ. Топам в письме в кратком виде указывались причины и содержание документа.
С этим да, страдаем...
А можете привести пример как было бы лучше?
@MaxRokatanskyВы не привели ссылки на Visual Paradigm и модель, о которых говорили в начале статьи.
Ваш фреймворк напоминает представление IT-ландшафта. Т.е. в вашем случае получается бизнес-ландшафт.
Т.е. ваши аналитики, кроме анализа и тестирования, решают когда и какому исполнителю выполнять таски?
Т.е. проверкой реализованного у вас заняты аналитики, а не тестировщики? Почему так? И почему код-ревью идёт после проверки реализации? Не потребуется ли проводить повторное тестирование если код не пройдёт код-ревью?
Приветствую!@aimfirst, уточните, пожалуйста, как ваши разработчики определяют какую задачу надо брать в работу? По канбану (верхний таск)? Как боретесь с тем, что берут в работу не то что сверху? Не думали-ли вы над тем, чтобы в Jira сделать кнопку, которая будет "выдавать и сразу запускать" таск в работу? Чтобы разработчик не терял время на выбор таски и у него небыло соблазна взять таск "что по легче".
Приветствую! @aimfirst, уточните, пожалуйста, как в описанном вами процессе проходят стадии анализа (описание аналитиками что надо сделать) и кодревью?
Аналогичный подход в Теории Ограничений Голдратта (ДТР и ДБР).
Задачи: выбор железа (микроконтроллеров/датчиков/...), их программирование, установка в тележку, модификация тележки.
Все вопросы на evgeny[at]cartpay.co.
Для шапки/сумки будет отдельный ключёк не влияющий на весы. Кота, просьба, оставлять дома :)
Пока производитель сам не будет наносить метки на свой товар, маловероятно что ритейл будет сам их клеить.