gifts2017

Опыт крупных проектов автоматизации для правительства г.Москвы и ГК Газпром

Опубликовал Никита Андреев (Andreev_N_O) в раздел Управление - Управление проектом

Хотелось бы вкратце рассказать про эти два проекта: • В компании Газпром, как ни странно, внедряется 1С:Предприятие. Вообще там внедрен SAP, но он не закрывает все участки учета, поэтому «лоскутно» внедряется 1С. Вначале там была система УПП, но потом стало понятно, что она не «вытягивает», и мы переписали некоторый функционал с нуля. И я в этом проекте выполнял функции ведущего разработчика. • В правительстве Москвы мы внедряли конфигурацию Бухгалтерия бюджетного учреждения (это был городской заказ). Я там выполнял функции руководителя проекта, и был в то время директором юридического лица - исполнителя по госконтракту.

Решение проблем с производительностью

Начнем с технических проблем.

Многим нравится, когда все данные по предприятию находятся в одной системе. Это удобно и для заказчика, и для программистов, которые жалуются на «лоскутную» автоматизацию, и для IT-директоров, которые озабочены концепцией единого информационного пространства. Но из-за этого появляются такие «монстрообразные» базы, где объем данных превышает несколько терабайт. А когда у нас в 1С базы начинают превышать определенный объем, возникают проблемы с производительностью. Что нужно делать в таких случаях:

  • Самое главное – это понять, на самом ли деле вам нужно, чтобы все эти данные были в вашей базе. Первое, что надо убрать – это файлы, они в базе не нужны, т.к. будут только увеличивать размер бэкапов, и получится, что мы каждую ночь будем в полном объеме их куда-то копировать и забивать диски. Это не очень рациональное использование пространства.
  • Еще бывает, что база разрастается просто из-за неправильного администрирования. Большинство таких проблем можно решить с помощью разделения баз данных на несколько путем вынесения этих баз на отдельные дисковые накопители (или на отдельные инстансы SQL). После этого система начинает работать более-менее стабильно.

Что по факту было сделано для повышения производительности?

  • На INFOSTART.RU мы нашли разработку, где было реализовано хранение журнала регистрации и версий объектов в отдельной SQL-базе. Мы стали ее использовать, и она нам очень помогла, потому что часть объектов все-таки надо было версионировать, а типовой функционал версионирования сильно нагружает систему. Единственное, что я в ней переделал – это чтобы записи создавались асинхронно с помощью фоновых заданий, потому что когда эта база набрала объем, она тоже стала вызывать замедление. А после того, как все это было переписано, транзакции перестали тормозить, и мы решили две проблемы:
    • Мы сохраняем информацию;
    • И в то же время у нас основная база и основной дисковый накопитель освобождены от этой странной работы по хранению.
  • Кстати, вынос части второстепенного функционала в фоновые задания, чтобы транзакции были короче, и не возникало блокировок – это довольно распространенный метод, советую использовать.
  • Следующее, что было сделано – это перевод на управляемые блокировки. При использовании автоматических блокировок могут возникать затруднения: пользователи ждут, им это не нравится, они выражают недовольство. А когда мы переводим систему на управляемые блокировки, такого не происходит.
    Но проблема в том, что мы не можем перевести на управляемые блокировки только один документ, мы должны перевести в этот режим все регистры, а значит, и весь функциональный блок. Это тяжелая работа, но, тем не менее, она оправдана.
  • Также нужно отметить, что высоконагруженные системы мы не имеем право отпускать в свободное плавание. Обязательно должен быть человек, администратор, который в режиме реального времени смотрит на дашборды и мониторит производительность нашей системы. В качестве дашборда может использоваться достаточно простая система Nagius. Там индикаторы имеют три цвета: зеленый, желтый, красный. Когда на горизонте беда, оно переключается в желтый цвет. Когда сервис блокируется – загорается красный. И даже можно настроить, чтобы приходила SMS – это очень удобно (хотя админу среди ночи получить "SMS счастья" не очень радостно, это лучше чем если поднимут ген. директора и он позвонит уже он самолично).
  • Также на Инфостарте была статья по РАУЗ, которая помогла нам добиться прироста производительности. Там в конфигурацию надо было внести буквально несколько изменений, и после этого происходил существенный прирост.
  • Еще хочу сказать по поводу нагрузочного тестирования: использование данных журнала регистрации для создания нагрузочных тестов приближает нас к тому, что мы имитируем типичную нагрузку. Например, в течение дня у нас проводятся какие-то документы, и если нам нужно проверить систему на устойчивость после внесения изменений, мы можем эти же документы просто перепровести и сделать при этом замеры. Если все получается хорошо, значит, что и в действующей системе все тоже будет хорошо. Понятно, что только проведения может быть недостаточно, потому что при реальной работе с формами могут выполняться еще какие-то дополнительные запросы к базе данных. Но, тем не менее, если мы перепроведем по журналу регистрации те же самые объекты – это будет уже больше похоже на жизнь, чем какой-то синтетический тест, который создает одни и те же документы, чтобы имитировать нагрузку.
  • Для разбора проблем с производительностью используется КИП.

Ну и в целом, достаточно прозрачно и понятно, куда надо копать: читайте книжку по Эксперту, анализируйте профайлером тяжелые запросы, изучайте планы запросов идобавляйте индексы.

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

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

Проблематика крупных проектов

Что касается пересечения технических и организационных вопросов:

  • К сожалению, если мы выполняем обязанности руководителя крупных проектов, нам приходится отходить от технических вопросов, от архитектуры в сторону коммуникаций, потому что кроме нас этого никто не сделает. Например, в проекте автоматизации правительства Москвы было плотно задействовано четыре организации, а значит, что со всеми представителями надо было постоянно встречаться и согласовывать то, что они хотят. Если они все находятся в центре, то четыре встречи можно и за день провести, но если они у вас территориально разнесены, или вообще участвует несколько городов, то это уже сложнее.
  • В тех случаях, когда требуется планирование, мы не можем пустить все на самотек, потому что если пытаться все держать в голове, то проект 100% завалится – следовательно, нужен соответствующий инструментарий.
  • Что касается инструментария, то самое первое – Google-документы. В современных телефонах для работы с ними есть практически все, что нужно. А если этого недостаточно, то потом подробнее расскажу еще и про инструментарий на базе 1С.

Что касается деятельности руководителя проекта, то основные моменты, которые обсуждаются у нас на совещаниях, это содержание и интеграция (потому что много систем взаимодействует между собой). И больше всего проблем возникает как раз с согласованием интеграционных вопросов, потому что у системы много хозяев, и каждый из них пытается «тянуть одеяло на себя». В связи с этим хотелось бы предостеречь коллег от ошибки:

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

Согласование требований

Что касается согласования требований:

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

Большинство проблем нужно стараться отсечь сразу, на этапе формулирования требований, чтобы избежать заведомо неправильных решений. Типичная ситуация: мы автоматизируем машиностроительный комплекс, и вместо одной сборочной спецификации хотим создать 10, по каждой операции (например, гайку прикрутили – новая деталь). Получается очень много промежуточных ходов, которые никто не сможет вести - слишком большой объем информации,тем более что в результате такого решения мы выигрываем только то, что видим остатки по этим гайкам в производстве (что мы их не сразу употребили на сборку, а по одной). Если это никому не нужно, и от таких вещей заказчика нужно уберечь. Поэтому сразу убирайте неправильные варианты.

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

Переходим к инструментарию, который был разработан для управления проектом.

Когда-то для этих целей мы в Газпроме использовали Jira, но потом сделали систему на 1С, потому что я, как Java-разработчик и как автор плагинов для Jira, могу сказать, что писать такие плагины довольно трудоемко: это занимает много времени и только лишь компилируется несколько десятков минут. Сейчас я считаю, что брать Jira и расширять ее плагинами – не очень правильно. Поэтому, раз уж у вас есть лицензия на 1С, лучше взять какое-то готовое решение или сделать его с нуля. Даже если вам, например, не нравится веб-клиент 1С, другой докладчик здесь же на конференции представил альтернативный, и это не может не радовать.

На слайде представлена архитектура нашего инструментального приложения. Конечно, это уже не газпромовская архитектура, потому что за то время, которое прошло с тех пор, мое видение сильно скорректировалось. Например, когда меня попросили разработать курс по управлению проектами в учебном центре при МГТУ им. Баумана, я, в процессе его проведения, получал обратную связь от участников. А когда людей и точек зрения много, это помогает снять замыленность взгляда. В том числе на основе этой обратной связи в архитектуру были внесены существенные корректировки. Поэтому на данном слайде отражен обобщенный результат этой архитектуры.

  • В центре вы видите большой блок управления денежными средствами. Он необходим в тех случаях, когда вы работаете с субподрядчиками, и вам надо управлять взаиморасчетами с ними, иначе у вас может случиться большое горе. Например, когда заказчик не перечисляет вам деньги, а у вас по договору с субподрядчиком уже есть обязательство, что ему нужно заплатить, чтобы он продолжал на вас работать. В этих случаях вы в платежном календаре видите провал (кассовый разрыв): вам еще не заплатили, а вы уже должны. И это – очень важная часть управления проектом.
    Но если у вас своя внутренняя команда и вам это не нужно, тогда – другое дело, тогда этот кусок можно выбросить.
  • Что касается планов, там также есть документы планирования.
  • Ну и самое главное, что в нашем инструментарии можно хранить все данные, которые у вас в голове не помещаются, и отслеживать их выполнение по реперным точкам.

По поводу работы с различными вариантами проектного инструментария у нас были дискуссии на предварительных встречах в «Клубе экспертов» – там люди говорили, что ничего из этого не работает, договорились даже до того, что методика GTD (Getting Things Done) не работает. Я с этим не согласен, мне это напоминает анекдот про блондинку, которая звонит своему мужу и говорит:

«Дорогой, я еду по трамвайным путям, за мной гонится трамвай, что мне делать?» На что муж ей отвечает: «Посмотри по навигатору, куда тебе ехать». А она ему: «Не могу посмотреть по навигатору, я с ним поругалась».

Соответственно и вы, как руководитель проекта, тоже можете со своим инструментарием «поругаться» и его не использовать, но на проекте за вами гонится не трамвай, который может остановиться, а дедлайн. И дедлайн не остановится, он вас задавит. А позвонить кому-то, кто решил бы эти проблемы за вас, вы, к сожалению, не сможете.

Заключение

На что еще хотелось бы обратить внимание?

  • Вчера коллега рассказывал, что если вы не пишете документов, то вы не управляете рисками. Однако даже если вы составили прекрасную документацию, но не установили порядок ее исполнения, то эти документы остались на бумаге и не пошли в жизнь вашей организации. Соответственно, вы все равно не достигли управления рисками, потому что, кроме того, что нужно составлять документы, гораздо важнее еще и фиксировать результаты мероприятий по рискам, вести мониторинг изменений вероятности реализации рисков. То есть, вы заложили риск смены собственника, и на момент начала проекта она была 5%, а в середине стала 95%. Самое время остановить работы и перейти на предоплату - но где тот красный огонек который об этом просигнализирует? В моей архитектуре это предусмотрено. 
  • Также в управлении рисками очень важно выделить особый риск, который связан с тем, что вы пообещали заказчику на пресейле. Например, вы пообещали ему увеличить производительность – такое же часто бывает? Для чего может быть нужна информационная система? Конечно, самый первый аргумент - для увеличения производительности, потому что нужно обслуживать больше заказов и производить больше продукции. Например, вы пообещали заказчику достигнуть каких-то определенных цифровых показателей. А потом, после того как вашими разработчиками было написано ТЗ, и согласно ему у заказчика прошло внедрение, вряд ли кто-то замерял, были ли достигнуты те значения показателей, которые были изначально обещаны. Может случиться, что после внедрения эти показатели даже ухудшатся. Почему? Потому что когда две системы работают в параллель, то очевидно, что человек тратит на них больше времени. Или, если он еще не привык к новой системе, и у нее есть какие-то недостатки, на работу тоже будет тратиться больше времени. И получается, что у вас вроде все юридически правильно: вы сделали систему, которая соответствует согласованному ТЗ (хорошо, если она соответствует). И юридически – вы правы, но по понятийным договоренностям – нет. Вы обещали улучшить, а получилось, что ухудшили. Поэтому очень важно замерять результаты обещанных показателей. Тогда можно выявить, что они еще не достигли целевых значений, и проанализировать, почему. Например, можно подойти с таймером к пользователю и замерить, сколько времени он тратит на оформление той или иной операции. И если он работает медленно, то сразу становится понятно, почему у него что-то не получается. А если не знать, что производительность упала, то, соответственно, и заниматься этим тоже никто не станет, и у клиента, даже если он заплатил вам деньги, все равно останется такое «послевкусие», что его обманули. А это очень плохо, потому что новых заказов вы от него больше не получите. Поэтому всегда измеряйте ключевые показатели, чтобы ваши клиенты были вами довольны.

Еще хочу сказать про разницу в отношении к коммуникационным проблемам у программистов и менеджеров.

  • Например, когда у программиста в плане работы над проектом раз в неделю стоит встреча с сотрудниками заказчика, а он с кем-то из них поругался, то он эти встречи прекращает, говорит, что у него сейчас много другой важной работы, надо код писать, некогда ему с кем-то встречаться.
    Или когда программист сталкивается с организационной проблемой (главный бухгалтер у него не хочет принимать работу), он на нее обижается, объявляет ее ведьмой-чернокнижницей и говорит: «мы с ведьмами переговоров не ведем, мы их сжигаем на костре». Что он делает дальше? Он начинает искать единомышленников и собирает толпу, чтобы действительно эту ведьму сжечь. Но за последние 10 лет я не слышал, чтобы кого-то из управленцев сожгли, или хотя бы уволили из-за конфликта с программистами: они не достигают такой степени влияния в организации клиента, чтобы по своему желанию кого-то увольнять. Значит, это – неконструктивная позиция, и если мы обрезаем коммуникации в период, когда начинаются проблемы – это совершенно точно путь к провалу проекта. И если дедлайн наступит, а мы ничего не сдали, то получится, что на нас лежала ответственность, а мы по каким-то эмоциональным причинам все провалили.
  • А менеджер – наоборот, в случае проблем усиливает коммуникации. Он может выслушать заказчика, не воспринимая его критику близко к сердцу, и это – то, что называется стрессоустойчивостью в требованиях к вакансиям. Тогда у человека запал пройдет, и мы сможем решить проблему более конструктивно: работы понемногу станут приниматься, документы подписываться и т.д. Бывало, я общался и по полчаса с людьми, только для того, чтобы снизить накал и перейти в конструктив. Да, это не просто, но после выработки иммунитета - вполне осуществимо.

Так что коммуникации – это очень важно, и выделенный менеджер, в частности, нужен именно для этого.

***********

Данная статья написана по итогам доклада, прочитанного на конференции INFOSTART EVENT 2015 CONNECTION 15-17 октября 2015 года

Приглашаем вас на новую конференцию INFOSTART EVENT 2016 DEVELOPER.

См. также

Подписаться Добавить вознаграждение

Комментарии

1. Виктория Дорохина (vikad) 23.03.16 09:01
Подскажите, пожалуйста, ссылку на статью по РАУЗ, которая Вам помогла
CSiER; tehas; NeviD; hulio; +4 Ответить
2. Владимир Бондарь (bondar_vy@mail.ru) 23.03.16 10:13
Добрый день.
Можно по подробнее узнать про описанную конфигурацию. Посмотреть и может быть купить со временем.
dock; inda; +2 Ответить
3. Алексей Соловьев (Silenser) 23.03.16 11:40
А уважаемый автор имел какое-либо отношение к компании Инвестгазватоматика?
4. Никита Андреев (Andreev_N_O) 23.03.16 12:22
Вот статья про кэширование ключей в РАУЗ
http://infostart.ru/public/306109/
По-моему, что-то еще делалось...
adhocprog; vikad; +2 Ответить
5. Никита Андреев (Andreev_N_O) 23.03.16 12:29
>> А уважаемый автор имел какое-либо отношение к компании Инвестгазватоматика?
Да, один из проектов по Газпрому был связан именно с этим названием, под эгидой Газпром Автоматизации на Саввинской набережной.
А с кем имею честь?..
6. Игорь Steelvan (Steelvan) 23.03.16 12:43
Большой и жирный минус за постоянное использование американизмов ! Автор, ты русский язык знаешь ?
7. Иван Петров (dgolovanov) 23.03.16 14:29
(6) Steelvan, Вам с Вашей американофобией к доктору надо.
1СERP; Irwin; karpik666; invertercant; gravisit; inda; +6 Ответить 1
8. Владимир Чаклин (vec435) 23.03.16 14:52
Скажите,пожалуйста, использовались в разработке методологии IDEF,UML?
9. Юрий Пермитин (YPermitin) 23.03.16 14:59
+

Было интересно почитать. Спасибо!
adhocprog; +1 Ответить
10. Алексей Соловьев (Silenser) 23.03.16 15:11
(5) Andreev_N_O, С бывшим руководителем отдела разработки вышеозначенной компании, в которой вы работали внешним разработчиком.
11. Евгений МелхОФФ (EMelihoff) 23.03.16 16:16
(6) Steelvan, работал в западной компании, где программист 1с был один я, остальные Java, PHP и т.п. Так вот в таких коллективах на "скрамах" общаются только на подобном "жаргоне" и люди уже привыкают и по русски даже не знают как сказать это. Проф деградация если хотите.
12. Никита Андреев (Andreev_N_O) 23.03.16 16:46
(8) vec435, конкретно в Газпроме по-моему нотация ARIS больше распространена - из тех компаний группы, где мне довелось общаться.
UML - для Java хороша, а в 1С-то из нее сущности как сгенерить? Изобрели какой-то инструментарий?
13. Никита Андреев (Andreev_N_O) 23.03.16 16:47
14. Максим Лесков (leskovma) 23.03.16 16:48
Спасибо большое за статью, было интересно ее читать
15. Алексей Соловьев (Silenser) 23.03.16 17:25
(13) Andreev_N_O, Крупный холдинг, преимущественно пищевка. Название не скажу :)
16. Игорь Steelvan (Steelvan) 23.03.16 23:33
(7) dgolovanov,

К доктору надо тем людям, которые считают что все американское это хорошо.

Как писал один:
Есть у меня старый ноутбук, работает плохо и уже слабенький, но он из Америки ! (тьфу)

И будет еще десять лет его в ручонках сжимать, думая что его сделали люди высшей расы (а на самом деле сделали китайцы и наклеили противный полосатый флаг).
17. Allexey (alex_4x) 24.03.16 09:08
Всё написано правильно. Но вот по поводу "Еще хочу сказать про разницу в отношении к коммуникационным проблемам у программистов и менеджеров." хочу внести небольшое замечание.
У Менеджера единственной задачей на проекте является коммуникации. Всё остальное - от архитектуры до реализации возложено на других участников проекта. Да, менеджер еще должен обеспечивать планирование и контроль, управлять рисками, предвидеть всё в целом и так далее, но все эти функции - это частные проявления комуникаций Менеджера проекта с внешним миром (заказчиками, ключевыми пользователями, внешними консультантами, кураторами проекта от головной организации и т.д) и с внутренним миром - командой проекта (архитектором, аналитиками, методологами, программистами и т.д.) Отсюда и вся суть - программисту не только в силу его характера, в большей степени из за того, что комуникации не являются его функцией и да, пардон - не оплачиваются - нет никакого желания тратить на это время. Вот и всё. Другое дело что конечно Менеджеру удобней, когда часть его работы возьмет на себя программист. Проведет опрос, обучение, сдаст блок или согласует спорные моменты ТЗ, но это говорит только о том, что Менеджер плохо выполняет свои функции и получает деньги за то, что его работу проделали другие. Браво конечно. Программисту никак не заставить Менеджера проекта кодить за него.
RomanRomans; JohnyDeath; TaTaPuH-Magic; AlenaR; Dem1urg; mymyka; mindcannon; Yashazz; CheBurator; +9 Ответить 1
18. Сергей valer (tank68) 24.03.16 10:04
Чем больше компания тем менее она поворотливая, никто не хочет брать на себя ответственность, а иногда чтобы что-то изменить нужна кипа встреч по поводу и без
19. Владимир Зленко (ZLENKO) 24.03.16 10:10
"Но проблема в том, что мы не можем перевести на управляемые блокировки только один документ, мы должны перевести в этот режим все регистры, а значит, и весь функциональный блок. Это тяжелая работа, но, тем не менее, она оправдана."

В УПП это в свойствах конфигурации одно свойство поменять...
В чем заключается "тяжелость" работы?
20. Владимир Зленко (ZLENKO) 24.03.16 10:17
"программист сталкивается с организационной проблемой (главный бухгалтер у него не хочет принимать работу), он на нее обижается, объявляет ее ведьмой-чернокнижницей и говорит: «мы с ведьмами переговоров не ведем, мы их сжигаем на костре». Что он делает дальше? Он начинает искать единомышленников и собирает толпу, чтобы действительно эту ведьму сжечь. Но за последние 10 лет я не слышал, чтобы кого-то из управленцев сожгли, или хотя бы уволили из-за конфликта с программистами: они не достигают такой степени влияния в организации клиента"

Конфликтовать с сотрудниками заказчика не стоит. Даже если они не правы. Нужно просто постараться минимизировать влияние этих людей на проект.
21. Женька Ture (ture) 24.03.16 10:31
Скока платят программистам 1С в газпроме?
И почему такой дурной тест на входе?
22. Богатырев Артур (Богатырев Артур) 24.03.16 11:06
(17) alex_4x, я бы еще добавил вот что - автор статьи ставит, что программист ОБЯЗАН встречаться с представителями заказчика. И он такой-сякой будет с ними ругаться, сволочь...
Вообще то на мой взгляд, для встреч с заказчиком, составления ТЗ, тестирования, уточнения ТЗ и т.п., если это крупный проект - должен быть не программист-кодер, но программист-аналитик (архитектор, глава группы разработки - как хотите называйте, без разницы). А то кодеру порой правда некогда. Да и не его это работа, как вы совершенно верно заметили.
А то может быть ситуация - весь такой белый-красивый менеджер "общается", а во всех проблемах виноват... программист. Подход "во всем виноваты программисты" он конечно прикольный, но не неправильный - ибо заказчик с таким же успехом может быть невменяемым, обладать скверным характером, менять свои показания и т.п. А виноваты... программисты....
AlenaR; alex_4x; +2 Ответить 1
23. Владимир Зленко (ZLENKO) 24.03.16 11:38
(22) Богатырев Артур, "А виноваты... программисты...."

Ну а кто ж еще? :-) Какие есть варианты? Будете доказывать заказчику что он не прав?
24. Капитан Немо (capitan) 24.03.16 12:20
Год назад 1 БИТ презентовал похожий мега проект. И если покопаться на инфостарте найдется еще парочка похожих.
При всех плюсах за решения по оптимизации БД они сникли при простом вопросе - А зачем ?
Есть такое понятие как декомпозиция БД.
Да, требование заказчика, чтобы все данные были в одной базе.
Но он под этим подразумевает прежде всего отчетность, а никак не то, что например ему надо обязательно расчет себестоимости делать всем в одной базе.
Знатоки меня поправят, но в типовых решениях зарплата считается по организации, БП закрывает период тоже по одной организации и т.п.
Т.е. простым РИБ по организациям можно свести супер мега дорогой сервер к нескольким.
Это и пользователям облегчит жизнь и службе безопасности и бюджет подэкономит в разы.
И автоматом решится задача с журналами регистрации.
А если удачно написать правила обмена и уйти от РИБ, то в центральной базе будет сводная аналитика и все просто взлетит.
Правительству Москвы это может и не сильно нужно, оно пил тратит бюджетные деньги, а вот акционерам Газпрома может быть интересно
25. Яков Коган (Yashazz) 24.03.16 16:20
Заумные красивости. Эффектные рассуждения людей в дорогих костюмах и галстуках.
Я тоже могу накатать такой трактат, исходя из сферических благих пожеланий в вакууме. А вот на практике у людей, красиво изъясняющихся на изуродованном русском, каковой они полагают профессиональным жаргоном, рисующих впечатляющие картиночки, схемки и графики, выходят всё больше кривые проекты с заваленными сроками. Опыт тут элементарный - изложены, в основном, моменты, которые лично мне очевидны совершенно, да вот только бесполезны.

...ах да, виноваты, естественно, программисты.
ZLENKO; alex_4x; +2 Ответить 1
26. Allexey (alex_4x) 24.03.16 20:55
Я ставлю публикации [+]
Не в моем плюсе смысл, я просто хочу сказать, что написано по делу, простым и ясным языком, красиво в конце концов. К спорам и обсуждениям автор готов, а не закрывает комментирование, как некоторые другие, не буду приводить ссылки, вы их увидите в топе по управлению.
В целом мне реально очень приятно видеть тут управленцев и очень приятно что они допускают обсуждение. Так мы и до комунизма и синергии доживём!
Я могу написать короткий очерк. Важная роль руководителя проекта. Где его спина-ваша жопа. Где ваша спина - его жопа. Когда в команде "АДМИНИСТРАТИВНО" а не только по понятиям выстроены правильные внутренние коммуникации - начинается парадигма роста. Каждый, понимая суть, старается максимально улучшить продукт, каждый со своей стороны, барьера внутренних коммуникаций нет. Ах я забыл.Это уже плагиат. Это же А. Гарин. Гиперболоид Инженера Гарина.
RomanRomans; +1 Ответить
27. Никита Андреев (Andreev_N_O) 24.03.16 21:18
(25) Yashazz,
>> людей в дорогих костюмах и галстуках

у вас откуда-то есть информация о стоимости моего костюма и галстука?..
единственный галстук который я купил задорого в Нью-Йорке, давно уже вышел из ротации, потому что был заляпан маслом из котлеты по-киевски.
остальные могут себе позволить все обладатели значка "1С: Специалист ".
или это вы какие-то свои комплексы продемонстрировали ненароком?

>>Я тоже могу накатать такой трактат

чтобы вы понимали, это не трактат, а стенограмма (с мизерными правками).
если вы можете, вам следовало 1) заявить на конкурс примерное содержание, 2) за него бы проголосовали люди, 3) вы бы выступили на конференции, и 4) потом бы вам предложили опубликовать стенограмму выступления.
если же вы как в том анекдоте, можете 30 раз за ночь, но только на словах - тогда да, остается писать такие посты.

>>красиво изъясняющихся на изуродованном русском

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

>>проекты с заваленными сроками

от сумы да от тюрьмы, как говорится, не зарекайтесь.

>>моменты, которые лично мне очевидны совершенно, да вот только бесполезны.

а вы под каждой статьей сообщаете в пол тыщи знаков, что она вам бесполезна, или только под моей?..

>> ...ах да, виноваты, естественно, программисты.

в статье, кстати, про вину ни слова не сказано - озвучена проблема, и способ решения - больше общаться с заказчиком и не зацикливаться на своих эмоциях.
даже этот совет отдельные читатели умудрились принять на свой счет и воспринять эмоционально...
28. Никита Андреев (Andreev_N_O) 24.03.16 21:37
(19) ZLENKO,
>> В чем заключается "тяжелость" работы?

1. имеем конфу где нет упр. блокировок.
2. пытаемся точечно перевести 2 документа и 1 регистр на упр. блокировки. так как вид блокировки определяет верхняя транзакция, тут же начинают валится сообщения о других регистрах, которые стоят на автоматике, а документы делают по ним движения.
3. переключаем эти регистры на упр. режим и их - добавляя собственно код блокировок в кучу мест.
4. оказывается, движения по этим регистрам делает еще 5 документов
... проходит несколько дней ...

впрочем, сам перевод галочками действительно элементарен. =)
29. aspirator 23 (aspirator23) 25.03.16 10:59
Если статья позиционируется как опыт очень крупных внедрений, то оставляет странное впечатление.
1.Пояснения о том как "боролись" за производительность описаны как сказал однажды Лустин в "методичке бауманского института за 3 курс".
Посмотрите для сравнения видео о Деловых линиях.
Кстати, если уж пригласили в МВТУ для написания курса об управлении проектами, посмотрите есть ли там та самая методичка. Или Лустин всех "развел"?
2.Часть об управлении проектами - общеизвестные истины.
3. Последняя часть - обрывочные абзацы, как будто их писала секретарь с диктофона,
а не специалист которые постоянно работает с документами и съел на этом две собаки.

"Очущение" такое, что единственное достоинство автора в том, что он умеет договариваться.
Это отличное качество, и часто его достаточно для ведения успешных проектов.
Но если так, то автору и нужно об этом писать, показать как правильно нужно договариваться,
а не пересказывать то что ему рассказали его программисты при внедрении.
Во всяком случае такая статья была бы на инфостарте действительно оригинальной, а если "с опытом из первых рук" - так еще и интересна.
30. Владимир Зленко (ZLENKO) 25.03.16 16:31
(28) Andreev_N_O, "1. имеем конфу где нет упр. блокировок.
2. пытаемся точечно перевести 2 документа и 1 регистр на упр. блокировки. так как вид блокировки определяет верхняя транзакция, тут же начинают валится сообщения о других регистрах, которые стоят на автоматике, а документы делают по ним движения.
3. переключаем эти регистры на упр. режим и их - добавляя собственно код блокировок в кучу мест.
4. оказывается, движения по этим регистрам делает еще 5 документов
... проходит несколько дней ... "

Галочку достаточно поменять всего одну :-) в корне конфигурации.
Блокировки прописывать не нужно - достаточно перейти на новую методику контроля остатков.
Все.
31. Михаил Зотов (ZOMI) 27.03.16 15:55
(30) ZLENKO, с таким подходом бюджет не освоить!) А как же переделка всех модулей и их дальнейшая поддержка?



32. EraZer (varjag) 28.03.16 10:26
Что подразумевает автор под паттернами ? Автор понимает вообще значение этого слова ?
Словоблудие какое-то.
33. Алексей Соловьев (Silenser) 30.03.16 10:16
(21) ture, Развенчаю миф о заработке программистов в Газпроме: большую зарплату там получают только люди с правильными фамилиями, которые подозрительно совпадают с фамилиями руководителей в головных организациях. В прямых дочках, зарплаты обычно не высокие, т.к. ограничены штатным расписанием, подвинуть которое есть задача на грани подвига. Поэтому, для того, чтобы нанять грамотного спеца используют дочерние организации (точнее, внучки), которые являются чисто коммерческими и штатка в них более лояльна к сотруднику. Зачастую может возникнуть ситуация, когда в отделе может сидеть несколько сотрудников из разных юр. лиц, но подчиняющихся формально одному руководителю.
Поднять зарплату потому, что повысилась стоимость специалиста на рынке - тоже довольно тяжелая задача. Поэтому обычно спецы, работающие в там получают выше среднего по рынку, под потолок рынка получают только те, кто являются ключевыми сотрудниками и руководство считает, что им нужно платить так, чтоб не ушли. Но чтоб таким стать, нужно отработать там от 3х лет и дольше и завершить пару проектов, которые запустили первые лица компании.
Однако, есть и плюсы. Обычно у сотрудников есть ДМС, оплачиваемый до 100% среднего заработка больничный, отпуск по ТК, ежегодная индексация оклада, нечастые переработки, премии ко дню газовика, на 8е марта и 23 февраля.
Резюмирую: Можно ли много получать работая в структуре Газпрома - да. Является ли это правилом, только на основании того, что вы работаете в одном из юр. лиц Компании - нет.
34. Артем Иванов (artemusII) 20.04.16 14:33
Спасибо огромное автору за статью. Читал на одном дыхании. В отличие от статей похожей тематики проста для понимания. Хотелось бы увидеть еще статьи этого автора.
P.S. Вопрос к автору: существует ли кратчайший путь (материалы, курсы и т.д.) чтобы обладать таким же опытом и знаниями как у вас?
35. Никита Андреев (Andreev_N_O) 21.04.16 10:56
(34) artemusII,
Здравствуйте, вам спасибо за добрые слова.
Не сказал бы, что обладаю каким-то недостижимым опытом/знаниями - если чем и обладаю, так это легкостью на подъем, благодаря чему оказываюсь в нужное время в нужных местах.
По 1С имеется не так уж много литературы, и если вы будете ее последовательно читать, вам никуда не деться от "Профессиональной разработки", и книги по "Эксперту".

Что касается курсов, я сам особо никуда не ходил, зато ввязался в преподавание, и волей - неволей пришлось изучить все на нормальном уровне (по зарплате, например, были серьезные пробелы в понимании механизмов вытеснения, перерасчетов).
Для расширения кругозора рекомендую не зацикливаться на 1С, а изучать другие языки - в моем случае Java, сейчас много читаю про Kotlin, думаю в нем есть потенциал.

Также рекомендую таки изучать предметную область, технологии производства, чтоб не выглядеть профаном, когда вы к примеру внедряя ERP, будете пытаться консультировать производственников на уровне "ты верно сосчитал овец, но оставь в покое мою собаку". =)
В моему случае это закончилось тем, что сейчас я пытаюсь на первом этаже дома из подручных материалов собрать фрезерный станок с ЧПУ, возможностями 3D печати из пластика и в будущем плазменной резки.
Для написания сообщения необходимо авторизоваться
Прикрепить файл
Дополнительные параметры ответа