Комментарии 31
Вспоминается начало 2000-х, когда в школах пытались учить VBA т.е. предполагалось, что компьютерная грамотность - это умение программировать в Excel. Каждый должен был бы уметь автоматизировать свою работу.
Ну это, кстати, хороший кейс, когда кто-то может самостоятельно свою работу автоматизировать.
Я когда-то, в позапрошлой жизни, был верстальщиком в еженедельной газете. А верстальщик, работавший до меня, тратил по несколько часов на финальное форматирование текста (всякие отступы, кавычки, выделения, стили). Довольно муторная скучная работа, которая требует большой внимательности. После такого глаза гарантированные красные. И так каждую неделю. И нет права на ошибку, т.к. потом газета отправлялась в типографию и печаталась тысячами экземпляров.
Помнится, я написал какой-то несложный скрипт, который делал всё это форматирование автоматически, за несколько минут. Об этой автоматизации я не пожалел))
Главное, чтобы о такой автоматизации бизнес не узнал. А то скажет "мы брали тебя на 8 часов в день, а ты отрабатываешь теперь только 2. Остальные 6 часов ты автоматизировал. Будем платить за 2. А за автоматизацию спасибо. Ты молодец"
Вместо Работы вы сделали Автоматизацию Работы - вы проявили инициативу и эта деятельность не была оговорена с шефом заранее. Значит вы поступили не как наёмный сотрудник, а как совладелец бизнеса. По-сути вы дали бизнесу сильно больше того, что предполагалось, причём бесплатно. Вам дали внеочередную премию или какой-то бонус?
Моя интуиция подсказывает, что не дали. Ведь так у нас заведено - бесплатное принимается, но не ценится.
Но в целом вы, конечно, правы. За такие действия надо доплачивать. Беда в том, что если вообще нужны такие действия, если ситуация провоцирует такие действия — значит, денег у компании нету. Будь у неё деньги, она бы уже наняла умельца и загодя такое сделала.
На моем опыте чаще компании (или руководители подразделений в больших компаниях) даже не знают о такой возможности. А потом "а что, так можно было?". И тут несколько исходов. В первом случае вас поблагодарили, стали относиться лучше, стали давать похожие задачи и всячески мотивировать. Бывает, что ничего не меняется кроме осознания, что у вас больше времени свободного и давай ка мы нагрузим вас всякими другими задачами (армейский вариант: кто не курит - тот копает). Честно говоря, ни разу не видел вариантов с увольнением после таких ситуаций, но не отрицаю, что такое может быть. Со мной лично была ситуация, что написанное мною требовалось при увольнении с мотивацией "это делалось в рабочее время на рабочем оборудовании" и не взирая на то, что все вокруг имеют такое же рабочее время и такое же оборудование, но делают это руками (не говоря уже о том, что работы много, и делал я это дома по вечерам). Бывшему руководителю я сказал, что всё снёс и это не вернуть, но заинтересованным исполнителям копию из бекапа восстановил после личной просьбы.
Ну мне тогда было двадцать с чем-то лет, я такими критериями не мыслил. Все было проще — работать неудобно, сделаю удобнее :)
Из бонусов я тогда заработал только респекты от коллег.
Ну и как верно написал Crystal_HMR, в редакции до этого никто и не предполагал, что этот процесс вообще можно автоматизировать.
Главное чтобы потом не получилось как в одной крупной на тот момент бумажной газете "известия", когда в ней в статьях стали регулярно проскакивать "служебные тэги", в районе 2002го гдето...
Ну это, кстати, хороший пример и подтверждение тезиса, что нельзя "раз и навсегда" сделать автоматизацию и просто забыть про неё :)
Не так давно
Издание «Газета.ру» назвало клинического фармаколога Олега Талибова «запрещённой в России организацией». Об этом в фейсбуке рассказал сам Талибов.
Приписка «организация запрещена в России» появилась в двух текстах, где упоминается Талибов — об опасности передозировки витамина D и приёме противомалярийного препарата мефлохин при профилактике коронавируса. Оба материала вышли в один день за подписью одного автора.
Так уж получилось, что я начал свой путь программиста с составления программок на VBA в Excel. Через полгодика кропротливого изучения был на работе полубогом. Ужасные, кривые, но рабочие скрипты очень-очень облагчали людям жизнь. Ощущение удовлетворенности от работы было на 120%.
Передернули вы, как минимум, раза 2, дальше было лень считать.
В кейсе, где автоматизируется НЕ бутылочное горлышко, вопрос не к автоматизации, а выбору цели. Причем здесь сама автоматизация?
Там, где нужно поправить параметры отчёта: если такого параметра изначально не было, аналитик потратит столько же времени на переработку отчёта. А если был, то автоматизация только в плюс
То есть, в общем, жёлтый заголовок, и порете вы хрень. Накидали бы вам минусов за такую вот спекуляцию.
аналитик потратит столько же времени на переработку отчётаАналитик потратит больше времени, т.к. это не то, с чем он работает каждый день + надо хорошо формализовать + поставить задачу разработчикам. Зато один раз, а не каждый день.
Проблема в том, что функции перекладывают с рядовых менеджеров, которые раньше делали такой отчёт, на ИТ-отдел. При этом, новых людей в ИТ не добавляют. Считается, что если что-то автоматизировано, то работа сделана, и больше не требует внимания. Но каждый день накидывают новое. А оно всё копится и требует поддержки на самом деле.
Ну у вас ведь есть система ведения отчетности о проделанной работе? Система трекинга времени? Если новые вещи не имплементируются или задачи выполняются долго - то нужно показать почему. Если отдел из N разработчиков тратит время на поддержку старых продуктов - то, к сожалению для них [разработчиков этого отдела], они должны доносить об этом руководству/заказчику. И либо нанимайте доп.персонал, либо откладываем реализацию новых фич и занимаемся рефакторингом старых проектов. Как правило, после рефакторинга оказывается, что как минимум третью уже никто не пользуется, еще третью пользуются единицы, а еще треть - это дублирующий функционал. Можно напрячься, сделать самим, нарисовать красивую презентацию о проделанной работе и прийти к руководству с запросом на повышение. В зависимости от развития событий - принимать соответствующие решения.
У ИТ отдела как правило не один заказчик. Но другие ведь справляются :)
Что бы понять чьи хотелки делать раньше - нужен некий скоринг заявок. Лучше, если этот скоринг будет делать бизнес. Если есть единый руководитель бизнеса - то в итоге он. Если нет - то пусть руководители бизнесов собираются и обсуждают друг с другом кто важнее.
А вот занятость разработчиков не волнует тех, кто сверху, пока руководитель разработчиков не может правильно донести до верхов текущую ситуацию.
Вообще, обычно не отвечаю на хамские комментарии.
"Передернули", "порете хрень", "спекуляции" — фу таким быть.
Но я вижу, что другие люди ваш комментарий читают, поэтому отвечу для них, а не для вас. Тем более это позволит глубже раскрыть некоторые тезисы статьи.
Типичная история именно для автоматизации:
Увидели проблемы в операционке → Автоматизировали операционку
Вместо этого, я предлагаю действовать так:Увидели проблему в операционке → Оцениваем её в масштабе всего бизнеса → Автоматизируем только если это повлияет на наши ключевые метрики
Конечно, так оценивать нужно любую задачу. Но, на моей практике, ошибки допускаются чаще именно при автоматизации. Думаю, это связано с иллюзией экономии, которую она дает.
Аналитикам, с которыми я работаю, обычно нужно 5-15 минут, чтобы подправить SQL-запрос. За это время можно разве что оформить задачу на разработчика, но точно не сделать её, не проверить её и не вылить её.
Плюс разработчик же не делает задачу в вакууме — он делает задачу вместо какой-то другой, полезной задачи. Я всегда очень осторожно отношусь к тому, чтобы грузить разработчика чем попало.
P. S. Солидарен с комментарием qw1 выше. Видно, что человек уже сталкивался с подобными ситуациями на практике.
На удивление полезная статья, написанная вдумчиво и доходчиво. Я сам сторонник спонтанной автоматизации - вжух-вжух и в продакшн. Меня постоянно сдерживали понимающие начальники, но только сейчас, прочитав эту статью, я понял почему они это делали, хотя они и пытались объяснить. Рекомендую к прочтению сисадминам - автоматизаторам которые работают соло.
Прошу прощения, но что-то какой-то странный продакт в вашей статье... Скорее местечковый проджект, без руководителя, на подхвате. Этакий проджект, не обременённый моральными принципами.. И в компании, видимо, не знают о такой вещи, как стратегия, которая включает в себя не только развитие бизнеса, но и развитие внутренней инфраструктуры.
Как вообще можно брать в работу проект без, хотя бы, предварительной оценки? Если разработчики тратят 50 "фантиков" на поддержку автоматизации, то может проблема в постановке задач? Или в костылях?
При всем этом, вы пишете и правильные вещи. Ну, которые прописные истины. Ощущение, что ваш продакт из статьи, далеко не матерый, а работает примерно 1-2 года и просто описывает свой путь проб и ошибок. Это не плохо, но статья должна называться по-другому в этом случае. А язык написания вполне хорош. Мне понравилось. Читается достаточно легко.
А пример с отчетом и Олегом шикарен... Если в течении года автоматизация помогает получать нужный отчет и только один раз в год нужно изменить настройки выгрузки - явно не стоит держать для такого отчета человека в штате.
И да, автоматизация может привести к увольнению сотрудника. А может и к перераспределению функционала. И тот и другой вариант работодателя устраивает. Вы же работаете не на коллегу, чьи действия можете автоматизировать, а на компанию?
Я ни в коем случае не сторонник увольнения всех и вся. Для меня интереснее освободить человека от рутины и дать ему другие задачи.
В общем, к чему я все это. Вредит не автоматизация. Вредит отсутствие проработки и понимания для чего это все делается и к чему приведет.
Предполагаю, что ваш опыт из другой области — возможно, вы работаете в аутсорсе? Я же говорю о работе над собственным продуктом. В любом случае, постараюсь ответить по пунктам.
Почему проджект? Разве проджект проектирует автоматизацию, общается с заказчиками, продумывает кейсы, пишет техзадание? У него ж совсем другая роль. Конечно речь о продакте или хотя бы бизнес-аналитике.
Смотря что вы имеете в виду под оценкой проекта. Если эстимейт задачи разработчиками — то, конечно, все оценивают размер задач, это обычная практика. Если же речь о финансовой оценке окупаемости каждой фичи или гипотезы — то это встречается довольно редко, только в компаниях с сильной продуктовой экспертизой.
Не очень понял вот это сочетание: "местячковый, аморальный и с опытом до 2 лет") Откуда такая статистика? Я собеседовал достаточно продактов из крупных городов и компаний, и вот что могу сказать: продакты с опытом до 5 лет очень редко умеют делать автоматизацию грамотно (не наворотить космолет, учесть все кейсы, качественно опросить заказчика и т.д.). В Белоснежку продакт превращается где-то на границе 5-7 лет опыта. Но, понятно, всегда есть исключения.
Конечно, никто не держит аналитика ради одного отчета. Но типичная ситуация, когда в обязанности аналитика, помимо всего прочего, входит и несколько регулярных выгрузок из БД.
С последним вашим тезисом "Вредит не автоматизация. Вредит отсутствие проработки и понимания для чего это все делается и к чему приведет" - согласен. Но как раз в этом и задача статьи — дать понимание "как повлияет автоматизация" тем, кто ещё не совсем это понимает :)
Если же речь о финансовой оценке окупаемости каждой фичи или гипотезы — то это встречается довольно редко
Эм, а на каком основании тогда вообще принимается решение о разработке фичи или анализе гипотезы? Как можно вообще начать что-то делать, не понимая хотя бы в первом приближении кому это нужно и во сколько это обойдется в дальнейшем?
Не, я понимаю если речь идет о хобби-проекте, но как это с бизнесом то соотносить?
О-о-о, вы бы удивились какой бардак творится в вопросах приоритезации бэклога!
Я довольно регулярно собеседую продактов — в основном мидл+ и синьор уровней. И, чтобы понять как они мыслят, всегда расспрашиваю — как они генерили гипотезы, как их приоритезировали и т.д.
Так вот даже в крупных компаниях часто берут в работу задачи, потому что "СЕО настоял", "команда очень хотела", "пользователи пожаловались", "конкуренты такое сделали", "оунер очень верил в эту идею" и т.д. В лучшем случае используют RICE или ICE методологии. Но реальную приоритезацию на основе прибыли, с учетом маржинальности, с расчетом срока окупаемости — такое делают единицы.
А самая дичь творится в госкорпорациях, там люди вообще не понимают слова "окупаемость". Мыслят категориями "освоить бюджет" и "руководитель так сказал". Я такого наслушался, что до сих пор кошмары снятся))
На фоне возрастающего спроса на RPA (robotic process automation), весьма ожидаемый отрезвляющий пост.
Я думаю что, грубо говоря, один специалист по Lean Management даст быстрее рост производительности, чем автоматизация без разбору.
Кстати, в применении к автоматизации тестирования, похожая картина. Автоматизация пилится, баги находятся, баги регистрируются, но клиентом не приоритизируются. Ну и нахрена автоматизация, если ты этой информацией по сути не пользуешься. Зачем ускорять накидывание багов в джиру? Чтобы потом через шесть месяцев выяснить что баг был починен случайно, в связи с чем-то другим. Т.е. автоматизация сама по себе, спринты сами по себе. Такая петрушка бывает, когда клиент заказывает автоматизацию тестирования, но не совсем понимает для что он собирается с ней делать. Он требует повышения покрытия, отчетов, собирает всевозможные метрики, а баги из автоматизации как лежали в багтрекере полгода назад так и лежат.
Еще, по моему опыту, люди упорно не хотят устранять очевидные препятствия. Они будут "спотыкаться о швабру", материться, эта швабра станет притчей во языцех, но не станут ее убирать на место. За наведение порядка во внутренних процессах клиент не платит, поэтому на это "времени нет". Так и будет валяться в бэклоге таск, что надо перестать делать миграции базы данных скриптами и принятъ на вооружение Liquibase. И тому подобное. Даже если есть свободное время, никто пальцем не пошевелит. И, что интересно, по моим наблюдениям, можно быть хорошим специалистом и при этом "не видеть" все эти потери эффективности. Наверное именно потому, что профессионалу "ничего не стоит" состряпать миграционный скрипт, или подправить что-то где-то руками в сотый раз. Ведь это как бы не так часто происходит. А если еще и менеджер человек заботящийся в первую очередь о закрытии обязательств перед заказчиком (читай "прикрытии своего тыла") то оно так и будет гнить потихонечку.
После прочтения даже зарегистрировался на habr, чтобы иметь возможность написать вам спасибо за статью.
Спасибо за хорошую статью. На предыдущем месте работы тоже воевал против "автоматизации". Хотя сам был в ДИТ.
На первом месте должны быть рентабельность, увеличение объема продаж, сокращение издержек. Так то по-хорошему, автоматизация часто это увеличение затрат (оборудование, программист на поддержку, сотрудник на первую линию и т.п.) без особого "выхлопа" для автоматизируемого процесса.
Позвольте людям работать руками (или почему вам не нужна автоматизация)