На протяжении последних 7 лет я работаю web-разработчиком. Год за годом я нарабатываю опыт, приобретаю новые знания. В целом мне нравится моя профессия.
Да я с белой завистью смотрю на крутых разработчиковв джавистов, питонистов они пишут драйвера к железу, нейросети и прочие страшные штуки. Мне, кого в данном обществе и за программиста не считают, наверное, грешно жаловаться, но очень хочется.
Наверное, все связанные с IT слышали фразу – «Автоматизируя хаос – вы получите автоматизированный хаос». Спустя 6 лет работы я продвинулся чуть дальше по карьере и стал микро руководителем. Целых три, таких же как я, кодера оказались в моем подчинении. “- Ух и разойдусь!” решил я, разберу забитую трубу заявок на разработку, займусь отладкой инфраструктуры, отдам проекты ребятам исходя из их сильных сторон, в общем все то, чем по моему мнению не мог заняться вышестоящий руководитель. И нет я не из тех, кто жалуется на плохое начальство. Просто такой микроменеджмент не их уровень, они думают о более стратегически важных вопросах и я с этим весьма согласен.
В первое время, понимая, что период бесконтрольного заведения технологий был весьма долгим, я кропотливо вникал в ряд проблем внутренних и внешних проектов компании. Свято веря в несовершенство кодовой базы и избранных программистами решений. За полгода работы с директорами департаментов, открылась истинная картина процесса подбора и разработки ПО. Оказывается, что на самом деле у нас имеется в системе электронного документооборота документ под названием “Заявка на доработку/разработку ПО”. Там древний файл ворда, в котором указаны требования к подаче заявки. И в этом файле нам и встречается первая преграда в виде “высшей математики”. Данную форму должен заполнять предположительно какой никакой руководитель. Вы не поверите но данное должностное лицо должно посчитать сколько человеко-часов будет экономиться при введении придуманной им автоматизации. Это конечно не так просто, но вполне реально. Тем более что просчет нужен не конечный, а достаточно приблизительный. Наш департамент рассчитывает затраты на производство, далее дается конечная финансовая оценка рентабельности данной разработки. И вроде все не сложно, но где-то в этом же мире живет тот самый розовый пони, которого мне так и не принес дедушка мороз.
“Это сплошная бюрократия“ — услышал я в ответ на просьбу заполнить данный документ от одного из руководителей. Хорошо, “Какой формат взаимодействия вы считаете наиболее продуктивным?”. Мы же живем во времена гибких методологий, не стоит держаться за пережитки прошлого. “Надо провести встречу я вам расскажу и покажу специфику задач и вы напишите техническое задание для программистов”. Думаю неплохо, живое общение чаще приводит к результату. Встречаемся, предмет беседы “Внедрение CRM и автоматизация отдела продаж”. На встрече волосы встают дыбом… Мне демонстрируют excel файлы, на первом вроде даже понятно всё. Не с первого взгляда, но понятно. Это блок-схема работы отдела продаж. Процентов 90 даже вписывается в реальность выбранного продукта. Второй файл вызывает удивление сравнимое со встречей инопланетян у себя в кабинете. Там поминутно расписан день менеджера по продажам. Переварив за некоторое время всю информацию, выясняю что данный тайм-менеджмент нацелен на автоматическую постановку задач. Пробиваясь сквозь дебри “автоматизации”, “закругленных процессов”, и прочего, выясняю факт. У данных задач нет никаких поддающихся анализу показателей. Пытаюсь донести “Если нет показателей никто не сможет контролировать корректное исполнение минимум 20+ задач помноженное на 20 менеджеров, не будет статистики, а следовательно контроля и задачи попросту не будут закрываться”. На что получаю весьма простой ответ “Ну а в чем проблема? Закрывайте их автоматически”. Снова пытаюсь донести глубокую мысль “Автоматически выставленные и закрытые задачи не несут в себе никакой автоматизации, расходуют ресурсы компании и мелькают в уведомлениях”. На что получаю ответ “Вы не правильно всё понимаете, я хочу чтобы в будущем мы могли сократить штат менеджеров и создать некоего универсального продающего робота”. Занавес.
Именно с этим директором одного из департаментов я почти больше не взаимодействую, произошло структурное изменение и теперь данные вопросы с директорами решают аналитики процессов компании и появившиеся проект менеджеры. Слушая разговоры и комментарии коллег понимаю что вектор совсем не изменился. До разработки дело так еще и не дошло.
Надеюсь вы поняли то что этот случай выступал как самый яркий пример. Такая ситуация твориться в нашей компании повсеместно, да, и хорошо подумав, я увидел данного персонажа, назовем его “автоматизатором”, и на прошлых местах работы. Это почти как вирус… “Автоматизатор” рассказывает другому и все — зараженный уже думает вот сейчас озадачу it-шников они мне за недельку всё автоматизируют и уволю я свой отдел продаж, сидят нахлебники бездельничают, и it-шников потом тоже уволю, они же уже все автоматизировали. Потом происходит столкновение с ценами на разработку, понимание что даже самой крутой программой автоматизации надо управлять. А чтобы грамотно управлять приложением оказывается надо читать какие то инструкции. И вот тут возникает претензия к программистам “Вы не можете сделать так чтобы работало без нашего участия!”.
Глобальность данной проблемы в том что эти люди руководители, управленцы. Они должны решать стратегические вопросы. Но им попросту лень. Ленивому руководителю легче требовать автоматизации, а не отлаживать внутренние процессы. Такой руководитель плодит некомпетентных, ленивых сотрудников, потому что ему лень подготовить сотрудника к работе. Любому новому сотруднику тяжело адаптироваться, тот кто наиболее коммуникабелен еще проявит инициативу. А остальные наделают ошибок, получат штрафы. Самые хитрые перевесят свои ошибки на несовершенство ПО, чью-то глупость, отсутствие регламентов и инструкций.
Иногда складывается ощущение, что работа программиста это делать людей глупее. Мы разрабатываем системы упрощения жизни не для того чтобы совсем не думать, а для того чтобы думать о чем-то более глобальном и важном. Выводы которые я сделал из данной ситуации в том. что теперь я принуждаю пользователей и заказчиков находить ответы там, где они лежат: в инструкциях, регламентах и всем том, что специалисты подготавливают для упрощения жизни пользователей. Пользуюсь правилом “незнание закона не освобождает от ответственности”. Да есть последствия на меня жалуются, ругаются и всячески проявляют негатив. Но я чувствую себя как после стоматолога. Каждый наученный пользователь это вылеченный зуб, который болеть больше не будет. Надеюсь, что смогу кого-то вдохновить на желание думать, а не автоматизировать собственную и чужую лень.
Да я с белой завистью смотрю на крутых разработчиковв джавистов, питонистов они пишут драйвера к железу, нейросети и прочие страшные штуки. Мне, кого в данном обществе и за программиста не считают, наверное, грешно жаловаться, но очень хочется.
Наверное, все связанные с IT слышали фразу – «Автоматизируя хаос – вы получите автоматизированный хаос». Спустя 6 лет работы я продвинулся чуть дальше по карьере и стал микро руководителем. Целых три, таких же как я, кодера оказались в моем подчинении. “- Ух и разойдусь!” решил я, разберу забитую трубу заявок на разработку, займусь отладкой инфраструктуры, отдам проекты ребятам исходя из их сильных сторон, в общем все то, чем по моему мнению не мог заняться вышестоящий руководитель. И нет я не из тех, кто жалуется на плохое начальство. Просто такой микроменеджмент не их уровень, они думают о более стратегически важных вопросах и я с этим весьма согласен.
В первое время, понимая, что период бесконтрольного заведения технологий был весьма долгим, я кропотливо вникал в ряд проблем внутренних и внешних проектов компании. Свято веря в несовершенство кодовой базы и избранных программистами решений. За полгода работы с директорами департаментов, открылась истинная картина процесса подбора и разработки ПО. Оказывается, что на самом деле у нас имеется в системе электронного документооборота документ под названием “Заявка на доработку/разработку ПО”. Там древний файл ворда, в котором указаны требования к подаче заявки. И в этом файле нам и встречается первая преграда в виде “высшей математики”. Данную форму должен заполнять предположительно какой никакой руководитель. Вы не поверите но данное должностное лицо должно посчитать сколько человеко-часов будет экономиться при введении придуманной им автоматизации. Это конечно не так просто, но вполне реально. Тем более что просчет нужен не конечный, а достаточно приблизительный. Наш департамент рассчитывает затраты на производство, далее дается конечная финансовая оценка рентабельности данной разработки. И вроде все не сложно, но где-то в этом же мире живет тот самый розовый пони, которого мне так и не принес дедушка мороз.
“Это сплошная бюрократия“ — услышал я в ответ на просьбу заполнить данный документ от одного из руководителей. Хорошо, “Какой формат взаимодействия вы считаете наиболее продуктивным?”. Мы же живем во времена гибких методологий, не стоит держаться за пережитки прошлого. “Надо провести встречу я вам расскажу и покажу специфику задач и вы напишите техническое задание для программистов”. Думаю неплохо, живое общение чаще приводит к результату. Встречаемся, предмет беседы “Внедрение CRM и автоматизация отдела продаж”. На встрече волосы встают дыбом… Мне демонстрируют excel файлы, на первом вроде даже понятно всё. Не с первого взгляда, но понятно. Это блок-схема работы отдела продаж. Процентов 90 даже вписывается в реальность выбранного продукта. Второй файл вызывает удивление сравнимое со встречей инопланетян у себя в кабинете. Там поминутно расписан день менеджера по продажам. Переварив за некоторое время всю информацию, выясняю что данный тайм-менеджмент нацелен на автоматическую постановку задач. Пробиваясь сквозь дебри “автоматизации”, “закругленных процессов”, и прочего, выясняю факт. У данных задач нет никаких поддающихся анализу показателей. Пытаюсь донести “Если нет показателей никто не сможет контролировать корректное исполнение минимум 20+ задач помноженное на 20 менеджеров, не будет статистики, а следовательно контроля и задачи попросту не будут закрываться”. На что получаю весьма простой ответ “Ну а в чем проблема? Закрывайте их автоматически”. Снова пытаюсь донести глубокую мысль “Автоматически выставленные и закрытые задачи не несут в себе никакой автоматизации, расходуют ресурсы компании и мелькают в уведомлениях”. На что получаю ответ “Вы не правильно всё понимаете, я хочу чтобы в будущем мы могли сократить штат менеджеров и создать некоего универсального продающего робота”. Занавес.
Именно с этим директором одного из департаментов я почти больше не взаимодействую, произошло структурное изменение и теперь данные вопросы с директорами решают аналитики процессов компании и появившиеся проект менеджеры. Слушая разговоры и комментарии коллег понимаю что вектор совсем не изменился. До разработки дело так еще и не дошло.
Надеюсь вы поняли то что этот случай выступал как самый яркий пример. Такая ситуация твориться в нашей компании повсеместно, да, и хорошо подумав, я увидел данного персонажа, назовем его “автоматизатором”, и на прошлых местах работы. Это почти как вирус… “Автоматизатор” рассказывает другому и все — зараженный уже думает вот сейчас озадачу it-шников они мне за недельку всё автоматизируют и уволю я свой отдел продаж, сидят нахлебники бездельничают, и it-шников потом тоже уволю, они же уже все автоматизировали. Потом происходит столкновение с ценами на разработку, понимание что даже самой крутой программой автоматизации надо управлять. А чтобы грамотно управлять приложением оказывается надо читать какие то инструкции. И вот тут возникает претензия к программистам “Вы не можете сделать так чтобы работало без нашего участия!”.
Глобальность данной проблемы в том что эти люди руководители, управленцы. Они должны решать стратегические вопросы. Но им попросту лень. Ленивому руководителю легче требовать автоматизации, а не отлаживать внутренние процессы. Такой руководитель плодит некомпетентных, ленивых сотрудников, потому что ему лень подготовить сотрудника к работе. Любому новому сотруднику тяжело адаптироваться, тот кто наиболее коммуникабелен еще проявит инициативу. А остальные наделают ошибок, получат штрафы. Самые хитрые перевесят свои ошибки на несовершенство ПО, чью-то глупость, отсутствие регламентов и инструкций.
Иногда складывается ощущение, что работа программиста это делать людей глупее. Мы разрабатываем системы упрощения жизни не для того чтобы совсем не думать, а для того чтобы думать о чем-то более глобальном и важном. Выводы которые я сделал из данной ситуации в том. что теперь я принуждаю пользователей и заказчиков находить ответы там, где они лежат: в инструкциях, регламентах и всем том, что специалисты подготавливают для упрощения жизни пользователей. Пользуюсь правилом “незнание закона не освобождает от ответственности”. Да есть последствия на меня жалуются, ругаются и всячески проявляют негатив. Но я чувствую себя как после стоматолога. Каждый наученный пользователь это вылеченный зуб, который болеть больше не будет. Надеюсь, что смогу кого-то вдохновить на желание думать, а не автоматизировать собственную и чужую лень.