Comments 20
Ну процессы наладились, значит способна. Несколько месяцев притирки для крупных проектов вполне нормальный срок. Принимать огромное хозяйство без содействия прошлой команды очень трудно (да и с содействием бывает не легко), и проблемы ожидаемы.
Специфика поддержки обычно предполагает менеджерские подходы, которые в конкретном кейсе сильно не сработали и пришлось перестраиваться в моменте
Одно дело, когда вы берете проект из технического интереса и хотите за счёт этого повысить свою экспертность, совсем другое дело, когда берете коммерческий проект и при этом даёте какие-то обещания клиенту, не имея хоть какого-то понимания.
Поддержу предыдущего комментатора - это не проблема команды специалистов, это проблема неправильного менеджмента.
Как результат, у клиента все стоит, ничего не работает, он терпит убытки и наезжает на менеджмент, который давал обещания. Менеджмент наезжает на спецов, а те в принципе не могут решить вопросы. Я бы из подобной конторы давно бы ушел.
п.с.
Видно, что статью писал менеджер. Понимаю, что возможно у вас действует NDA, но вы хотя бы написали общую информацию, для чего предназначен софт, с какими проблемами сталкивался заказчик, как их решали и т.д.
С точки зрения бизнеса правильность или неправильность измеряется в деньгах. Если это приносит деньги, хоть через боль и через слёзы, и не умирает за N лет, то вполне имеет право на жизнь. В экосистеме у всех свои ниши. Даже в канализации кипит жизнь.
Описывали менеджерские процессы больше, но если интересно о чем софт, то он предназначен для реализации программ лояльности у заказчика. Система предполагает работу с большим количеством данных в БД (ETL процессы, сегментация данных, realtime обработка входящей информации и тд). Из проблем, которые сразу были наиболее критическими: производительность, ошибки при отработке бизнес-процессов (не правильные данные, конечный пользователь видит в приложении неверную информацию, неверно работают бизнес-акции и тд). По техническому решению таких проблем возможно будет отдельная статья
Нет ни документации, ни исходного кода, ни мониторинга.
Анализируя проблемы одну за одной, мы пришли к решению каждой путём
чёткого структурирования процессов и применения техник Agile.
Решение проблем при отсутствии исходного кода, документации и мониторинга путём структурирования процессов и внедрением Agile - звучит невероятно круто.
"Вы прослушали точку зрения менеджера на то почему он молодец, а теперь дадим слово самим специалистам"
А дальше будет непереводимая матерная речь... По поводу проекта и менеджмента))
Ситуация, когда у проекта не было ни исходного кода, ни документации, ни мониторинга была сложной и для команды. Специалисты сами пришли за помощью к менеджерам, потому что уже не было сил разрываться между запутанной техникой и поддержкой управленческих процессов
Осилил. Выскажу мнение что вы решили задачу тупо затянув все гайки. Введя максимальное количество совещаний как внутренних так и внешних, заставляя писать комментарии к заявкам, документации, мануалы итд. Представляю как команда вешалась при таком раскладе ... Пытаетесь донести до аудитории, что такой по сути совковый подход, это не такое и плохое решение?
Мне довелось работать и при совковом подходе (стиль управления Диктатор) и при современном (Лидер+Менеджер). И именно при свободном подходе у меня КПД было самое эффективное.
Дисциплина как и профессионализм зависит прежде всего от набранных работников, а не от того, что ситуация требует. Профессиональный инженер как минимум сам для себя пишет мануалы или заметки оставляет как решил проблему. Профессиональный инженер будет решать проблему, если будет грамотно и понятно поставлена задача. Тут больше вопросов именно к руководству этой команды, а не к исполнителям и уж выдавать за заслугу, то что задушили максимально исполнителей заявок это уже совсем некрасиво.
Эта статья, яркий пример того, как делать не стоит. При этом они пишут о многолетнем опыте на рынке по поддержке таких проектов.
Сугубо мое мнение, специалисты у них молодцы, менеджеры не очень. Особенно некрасиво то, что менеджер себе в заслуги ставит решение проблем...
Я именно об этом и говорю. Очень интересно было бы послушать отзыв непосредственно исполнителей. Уверен много чего узнаем о компании и руководстве =)
Решение отлично сработало в таком кейсе. Соглашусь с тем, что постоянное напряжение как в армии на работе не хорошо для команды, но здесь было немного иначе. И команда и менеджмент понимали всю критичность ситуации и совместно были готовы "затянуть гайки". По итогу все пришли к более лояльным процессам (которые и не роняют теперь проект) после решения накопившихся проблем
Выглядит, как будто команда замахнулась на то, что ей не по зубам - просто по причине количества.
А как проект поживает? Пациент жив, или скорее, мёртв? )
Мне кажется, что чтобы прочувствовать всю суть ситуации надо сначала себя поставить на место заказчика, который остался наедине с огромной системой и не знает что делать, а потом представить что вы подрядчик, который принял совсем непростой вызов
Вендор ушёл, а реквизит остался. Как мы начали сопровождать «чёрный ящик»