В предыдущей статье мы вели рассуждения о том, почему компании нужно перейти на новую CMS, какую именно и как это все обосновать руководству компании, чтобы это все ещё прошло…
Почему одобрили Ваши предложения, и устраивает ли это Вас?
Рассматриваем вариант, что руководство вроде бы как одобрило текущий подход. Конечно, круто. Но вот меня настораживает ситуация: Вроде бы… Наверное… Если мы ничего при этом не потеряем, то пусть… Не знаю как вас, но меня такая ситуация не устраивает. Мне хочется понимать, что люди убедились, что это самый правильный подход в текущих реалиях. И, в случае возникновения сложностей с разработкой, с дизайном и т.д., я не оказался крайним. Ну, потому что это не правильно. Должно быть единое понимание того куда двигается компания. Хотя, видны нотки перфекционизма. 🙂
В общем меня такая ситуация не устраивает. Я начал оценивать, почему так произошло?
- Недостаток информации? – Возможно
- Малый вес ваших слов? – Скорее всего
- Узкое мышление? – Вполне может быть
P.S. Это, своего рода, этап самокритики. Вы должны научиться задавать себе честные и правильные вопросы…
1. Возможно, вы не полностью смогли изучить вопрос и правильно его представить людям, которые принимают решение. Поэтому нужно ещё раз тщательно посидеть и подумать, что из аналитических сводок, из статистики, из тенденций рынка можно взять в виде доказательства вашей идеи.
2. Малый вес ваших слов или поиск союзников
О, это хотя и очевидно, но стало для меня открытием, что такую вещь можно использовать как методику. Что я имею ввиду? Т.к. вы новый человек в компании, то вам не особо, то и доверяют. Но вы точно уверены, что ваши действия правильные и нужно как-то добавить веса вашим словам. До этого основной упор был в том, что доказательство идет из одного места, снизу вверх, по карьерной лестнице. Идея состоит в том, что можно походить «по горизонтали» (познакомиться с менеджерами направлений, с аналитиками IT отдела, с штатными программистами и т.д.), у которых есть проблемы в рабочем процессе и которые могут поддержать вас в решении, которое вы продвигаете. Ситуация, которая была у меня, менеджер направления продвигал ровно такую же идею по своему направлению. Что мы сделали? Конечно, объединили усилия и на следующее совещание пошли уже вместе. В виде предварительной подготовки собрали коммерческие предложения от компаний, которые готовы заняться нашим решением на новой CMS и от старой компании, которая ведет кастомную разработку. Получилось, что под Bitrix стоимость разработки такого же решения с нуля оказалась дешевле чем делать доработки в текущем кастомном решении. Плюс ко всему, пошёл в отдел IT, нашел аналитика, который занимается описанием IT архитектуры, и попросил его проанализировать вопрос на тему: «Как впишется переход на CMS Bitrix в текущую архитектуру, сколько это будет стоить, как повлияет то, что уйдет WordPress с горизонта и т.д.». И вы знаете, тоже помогло J Все эти люди могут «прибавить веса» вашим словам. Как провернуть такое в вашей ситуации? Думайте. Но это работает.
3. Узкое мышление. – Что я имею ввиду?
Если вы приходите на новое направление и начинаете гнуть свою линию, то может сложиться впечатление, что вы просто тянете одеяло на себя. Естественно, коллегам из соседних отделов, на которых влияют решения, которые вы продвигаете, это может, не понравится. И вы столкнетесь с эффектом естественного противодействия и это нормально.
Взаимодействия двух тел друг на друга равны между собой и направлены в противоположные стороны
Исаак Ньютон
В итоге получится 🙂 Вы будете стоять на месте.
В этой ситуации предлагается посмотреть на вещи под другим углом. В данном случае не в рамках работы каждого отдела, а на ступеньку выше, посмотреть на процессы, которые сейчас реализуют эти отделы. И проанализировать, как все происходит. Может получиться очень интересная ситуация.
Проанализировав вопрос на уровне процессов получилось, что сейчас ведется разработка на Back-end -> ведется разработка SOAP решений на Back-end -> ведётся разработка панели администрирования на Back-end -> ведётся разработка в панели администрирования WordPress -> ведётся разработка на «Морде» сайта. Такой процесс. Происходит явное дублирование работ, что приводит к увеличению затрат на разработку.
Как можно действовать? – Делать «Сквозные» процессы, т.е. вести разработку нужных блоков либо по вертикали, что я называю Собственной разработкой или In House решением. Иди вести разработку по горизонтали в рамках «Сквозного» процесса, что будет означать некую автономность систем. Но в этом случае удаётся избежать дублирования работ.
| Плюсы: | 1. Полный контроль всего процесса 2. Разрабатывается только необходимый функционал 3. В долгосрочной перспективе возможна выгода в качестве оптимизации ресурсов 4. Нет дублирования работ |
| Минусы: | 1. Расширение штата на разработчиков, аналитиков 2. Риски доступности сервисов. Одна проблема влияет на весь процесс. Встает вся система. 3. Краткосрочная и среднесрочная перспектива — видимое удорожание вывода услуги на рынок |
| Плюсы: | 1. Удешевление процесса за счет Единого стандарта работы на всех уровнях 2. Сокращение времени вывода услуги на рынок 3. Уменьшение рисков не работающей системы. 4. Нет дублирования работ |
| Минусы: | 1. Удорожание расходов на старте. Во время перестройки процессов. 2. Отказ от текущей схемы потребует новой разработки в новой архитектуре 3. Необходимо инициировать процесс со стороны управления компанией, т.к. должно быть налажено полное взаимодействие между отделами. |
В случае 2 (In House) получается, что участие CMS вообще не требуется. Но этот подход имеет место на жизнь. В случае 3 (Горизонтальное масштабирование) возможен переход к новой системе управления сайтом.
Статья получилась длинная, но кому-то может и помочь, или просто будет интересно познакомиться с чужим опытом. В любом случае, подходите к решению проблемы с умом, опираясь на текущую ситуацию вокруг.