Рано или поздно каждый продакт становится достаточно матёрым, чтобы грамотно автоматизировать любую ручную работу:
Финотдел тратит время на отчет? Вот вам кнопка, жмите, отчет сформируется автоматически!
Аналитики делают ручные выгрузки? Вжух, и у нас теперь красивый автоматический дашборд!
Сэйлзы заполняют данные о клиенте вручную? Хоп, и данные уже парсятся автоматом!
Тогда продакт начинает чувствовать себя этакой Белоснежкой, которая улучшает всё, к чему прикоснется. Да и коллеги его хвалят — ведь всем нравится, когда что-то делалось руками, а теперь работает «само по себе». Пусть вкалывают роботы, а не человек!
Но это ошибка.
На длинной дистанции автоматизация часто бесполезна и даже вредна для бизнеса. А продакт – как раз тот человек, который должен предостеречь окружающих.
Сегодня расскажу, как вовремя распознать зловредную автоматизацию.
Не все автоматизации одинаково полезны
1. За комаром не ходь с топором
Как правило, в каждом бизнесе есть бутылочное горлышко или точка ограничения, которая мешает масштабировать прибыль. Любая деятельность, которая не ведет к устранению этого ограничения, – малополезна для бизнеса.
Это плюс-минус очевидно.
Но когда речь заходит об автоматизации ручной работы – редко кто задается вопросом: «А как это повлияет на наши ключевые метрики?».
Допустим, вы прокачали маркетинг и трафик на сайт льется рекой. Потенциальные клиенты заходят и оставляют заявки на обратный звонок. Но у вас всего 2 сэйлза, которые физически не успевают прозвонить все заявки.
Нужно ли в этой ситуации фокусировать силы вашей небольшой IT-команды на улучшение инструментов финотдела? Очевидно, нет – прямо сейчас это никак не поможет бизнесу, не даст роста прибыли.
Если очень хочется что-то автоматизировать – лучше сделайте скоринг заявок, чтобы сэйлзы знали, какие заявки прозванивать в первую очередь. Но хитрость в том, что обычно проще нанять еще 10 сэйлзов, чем что-либо программировать.
2. Кошке игрушки, а мышке слёзки
Конечно, не всегда автоматизация – это про кратный рост и масштабирование прибыли. Иногда это просто желание сэкономить. Мол, сейчас тратим деньги на ручную работу, автоматизируем её и будет экономия!
Что ж, звучит неплохо.
Но на практике автоматизация чаще ведет не к экономии, а к замене одних расходов другими.
Например, саппорт жалуется: «Мы ежемесячно тратим время на эту рутину! Давайте ее автоматизируем!». Продакт-Белоснежка уже потирает руки – он умеет решать такие задачи и сейчас всё сделает в лучшем виде!
Вот что произойдет дальше:
продакт потратит неделю на проектирование автоматизации;
разработчики потратят ещё неделю-другую на её реализацию;
результат выльют на продакшн;
саппорт немного порадуется, ведь ручной работы стало чуть меньше;
а ручной работой теперь будут заниматься уже разработчики, вынужденные поддерживать эту автоматизацию (документация, регрессия, поиск-починка багов, хотфиксы и т.д.);
также вырастет сложность проекта, а значит, все будущие доработки функционала будут стоить дороже;
в итоге мы тратим 50 фантиков на работу высокооплачиваемых разработчиков вместо того, чтобы тратить 5 фантиков на работу саппорта!
Суть в том, что не бывает автоматизации, которая работает сама по себе. На самом деле вы просто заменяете одни процессы другими, зачастую более дорогими и сложными.
3. Где растяпа да тетеря, там не прибыль, а потеря
В разработке продукта практически не бывает задач, которые можно сделать «между делом». Пока время, энергия и фокус команды тратится на очередную автоматизацию – вы упускаете возможность найти реальные точки роста продукта и поработать над ними. А ваши конкуренты, тем временем, с удовольствием занимают рынок.
Есть типичная трагикомедия в двух действиях, которую раз за разом разыгрывают сотрудники операционных отделов.
Трагикомедия «Шеф, всё пропало!»
Действие первое, трагедия.
Прибегает к вам, скажем, руководитель отдела продаж.
Картинно заламывая руки, он говорит, что мы на грани катастрофы и если срочно не автоматизировать использование промокодов – то продажи рухнут, а квартальные цели компании будут безнадежно загублены. Судьба полимеров в ваших руках! Заодно он в красках расписывает, какие невыносимые мучения испытывает каждый рядовой сэйлз из-за необходимости вручную обрабатывать промокоды.
Вы, конечно, бросаете все дела и срочно продумываете автоматизацию промокодов. Закидываете хотфикс в спринт, а разработчики в поте лица овертаймят, чтобы быстрее вылить столь необходимый функционал. Сроки спринта сдвигаются, а иногда из него выкидываются какие-то другие задачи.
Действие второе, комедия.
Наконец, вы выливаете долгожданную автоматизацию на продакшн.
Проходит неделя, другая – вы смотрите аналитику. И видите, что промокод ввели буквально несколько пользователей.
Как же так? Ведь это такой важный функционал, от которого зависит будущее компании! Вы идете к заказчику, чтобы выяснить, в чем же дело.
А он и говорит: «Та чет маркетинг пока занят, они отложили интеграции с промокодами, туда-сюда, пятое-десятое... Короче, скип».
Проходит ещё полгода, и вы понимаете, что этот функционал просто не используется. То есть весь этот кипиш был зря. Сэйлзы забыли про эту задачу уже через неделю, а разработчики до сих пор вынуждены поддерживать её работу, проверять на регрессии, чинить баги и так далее.
Мораль сей басни такова:
Каждый отдел искренне считает свои задачи самыми важными, это нормально.
Операционные отделы, как правило, стараются операционку сократить – это тоже нормально, ведь они ищут способы оптимизировать свою работу.
-
Но продакт должен с холодной головой оценивать реальные риски и выгоду для бизнеса. Для этого нужно сделать всего две вещи:
Досконально разобраться: что делаем и зачем, как это работает сейчас и как будет работать после автоматизации.
Открыть Excel или Google Sheets – и посчитать окупаемость предлагаемой автоматизации.
Если продакт излишне доверчив или стесняется сказать «нет» заказчику, то это беда для компании, в которой он работает.
4. Ты ему о деле, а он: приходи на неделе
Допустим, ваш аналитик регулярно делает ручную выгрузку данных по продажам. Если вам нужно разово поменять условия этой выгрузки – вы просто говорите ему: «Олег, давай в этот раз без европейских клиентов».
И Олег рад стараться, ему так даже интереснее.
Но совсем другая история, если вы уже автоматизировали эту выгрузку. Теперь, если вам нужно изменить условия, то это превращается в проблему:
придется или ставить задачу на разработчиков и ждать выливки,
или пилить админку для управления настройками выгрузки.
А если эта информация нужна вам срочно?
И не забывайте, что проверить корректность полученных данных всё равно сможет только живой аналитик.
Здесь нет простого решения, всегда будет дилемма: менять настройки руками разработчиков или пилить дополнительный функционал для управления настройками. И то и другое дорого, медленно и усложняет архитектуру. В отличие от Олега.
5. Пустую воду как ни вари, а навару не будет
Нередко бывает и так, что нужно не автоматизировать процесс, а просто избавиться от него.
Например, фины просят автоматизировать отчет, который стал занимать слишком много времени. Худшее, что можно сделать в этой ситуации, – сразу начать думать, как бы лучше сделать автоматизацию.
Лучше сначала разобраться: кому этот отчет нужен и зачем. Иногда, к удивлению самих финов, оказывается, что отчет делается просто по традиции и сейчас он уже не востребован. Или что похожий отчет уже есть в какой-нибудь системе аналитики, просто фины с ней не работают. Или отчет нужен только для расчета KPI, и тогда проще поменять систему KPI, чем городить автоматизацию.
6. Курочка по зёрнышку клюёт, да сыта бывает
Даже в ситуациях, когда автоматизация какого-то процесса оправдана, – зачастую не оправдана полная его автоматизация.
Обычно можно разбить операционный процесс на несколько частей. Например, сначала автоматизировать самое трудоемкое, а остальное оставить в ручном режиме.
Это позволит:
быстрее продумать и реализовать задачу;
быстрее снять операционную боль и дать профит бизнесу;
уменьшить риски и стресс при переходе на новую систему;
убедиться, что автоматизация действительно решает проблему и что ей реально пользуются;
собрать фидбек и учесть его при автоматизации следующей части;
а если что-то пойдет не так – откатить всё обратно дешевле и проще.
Поэтому если вы решились делать автоматизацию – сделайте её частично и посмотрите, как это сработает.
7. Без дела жить – только небо коптить
Если откинуть все рациональные доводы, то останется последний, эмоциональный:
Но люди же страдают!
Они делают руками то, что может делаться автоматически!
Я хочу им помочь!
Хорошо, давайте представим, что будет, если вы действительно автоматизируете их работу. Эти сотрудники станут просто не нужны (как минимум – в таком количестве). Неужели помощь заключается в том, чтобы их уволить?
Нет ничего плохого в том, что люди делают что-то руками, если это взаимовыгодная сделка:
бизнес получает результат, и это быстрее-дешевле-гибче, чем пилить автоматизацию;
сотрудник честно трудится и получает за это зарплату;
используя заработанные деньги, он развивает экономику своей страны;
государство получает рабочие места и налоговые поступления в бюджет.
Не нужно рушить эту идиллию своей навязчивой автоматизацией!
Хозяйке на заметку
Резюмируя, вот краткий список вопросов, которые стоит задать себе прежде, чем браться за любую автоматизацию:
Влияет ли эта автоматизация на ключевые метрики бизнеса? Поможет ли она масштабировать прибыль?
Сколько денег ежемесячно мы тратим на ручную работу, которую собираемся автоматизировать?
А сколько прибыли приносит процесс, который мы собираемся автоматизировать? Может, лучше от него вообще отказаться?
Насколько автоматизация окупится с учетом стоимости её разработки, внедрения, поддержки?
Как мы будем менять настройки автоматизации,
есликогда возникнет такая необходимость?Должны ли мы автоматизировать весь процесс целиком или можем начать с малой его части?
Хорошая, годная автоматизация
Конечно, не любая автоматизация вредна. Навскидку я могу вспомнить 5 кейсов, когда автоматизация целесообразна и оправданна:
1. Госуслуги
Когда мы говорим об операционных процессах, которые затрагивают миллионы людей, – любая автоматизация будет заведомо выгодной.
Вы делаете в приложении кнопку «Сменить адрес прописки» – и вот уже миллионы людей не стоят в очередях, не общаются с хамоватыми бюрократами, не тратят дни на минутные дела!
2. Большие корпорации
Если у вас стартап на 5 человек, то при найме нового сотрудника не сложно рассказать ему всё необходимое лично.
Когда у вас в штате 50 сотрудников, то лучше, чтобы за онбординг новичков отвечал отдельный человек.
Ну а если в компании уже сотни сотрудников, то разумно будет использовать LMS, чтобы поставить обучение новых людей на поток.
Правда, в случае с LMS или CRM – проще брать готовые решения, чем пилить что-то своё. Но в целом мысль такая, что чем больше компания, тем чаще оправдана автоматизация её внутренних инструментов.
3. Выход на новые рынки
Иногда вам нужно быстро проверить востребованность продукта на новых рынках – скажем, в десятке стран сразу. Представьте, как непросто нанять рекрутеров, сэйлзов, саппорт даже в одной незнакомой стране (с учетом местного законодательства, менталитета, рынка труда). А найм сразу в десяти странах вообще затея на грани фантастики, особенно если у вас раньше не было такого опыта.
В таком случае разумнее запускаться с автоматической воронкой продаж, если ваша бизнес-модель это позволяет. Да, конверсии наверняка будут хуже, но зато вы оцените востребованность продукта сразу во всех выбранных странах. А наращивать операционку сможете уже там, где даже автоматическая воронка дает нормальный результат.
4. Подготовка к масштабированию
Например, вы привлекли следующий раунд инвестиций и собираетесь потратить полученные деньги на привлечение новых клиентов. Но иногда кратный рост клиентской базы требует также кратного расширения операционных отделов.
И тогда вы оказываетесь перед выбором – нанимать десятки новых сотрудников или автоматизировать их работу. В такой ситуации автоматизация может быть хорошим решением.
5. Работа с B2B-клиентами
Допустим, вы работаете с корпоративными клиентами и каждый из них – это десятки или сотни пользователей вашего продукта. Если значительная часть этих клиентов испытывает какие-то неудобства, то лучше это исправить.
Например, руководителям компаний нужен ежемесячный отчёт по прогрессу своих сотрудников. Лучше дать им кнопку, по которой они этот отчёт получат, чем готовить такие отчёты в ручном режиме.
Разница с обычной автоматизацией здесь в том, что вы не только избавляетесь от ручной работы, но и получаете конкурентное преимущество для своего B2B-продукта. А это помогает привлекать новых клиентов и удерживать старых.
Расскажите в комментариях, если сталкивались с другими ситуациями, когда автоматизация хорошо окупалась.
Заключительная мысль
Возвращаясь к нашему продакт-менеджеру: фокусировка на автоматизации может навредить не только его продукту, но и ему самому. Вместо того чтобы думать о высокоуровневых метриках, он находит себе рутинные доработки и вязнет в них, иногда на годы.
Чтобы профессионально развиваться, продакту нужно научиться сдерживать свое желание хаотично улучшать всё подряд. Начать смотреть на продукт не как «Белоснежка-улучшатор», а как шахматист, который видит всю ситуацию на доске и понимает, куда сейчас нужно приложить усилия.
P. S. Выше я рассказал об автоматизации операционки руками собственных разработчиков. Но это не единственный возможный путь – есть же и готовые сторонние решения. Но их я умышленно оставил за скобками, потому что там отдельная история: свои плюсы-минусы, свои риски и подводные камни. Плюс, когда речь идет о покупке стороннего решения, обычно все скрупулезно считают окупаемость, ведь платить придется ежемесячно.
К самостоятельной же автоматизации нередко относятся более легкомысленно. Надеюсь, моя статья поможет иначе взглянуть на этот вопрос.
Комментарии (28)
dth_apostle
24.12.2021 22:22+3Передернули вы, как минимум, раза 2, дальше было лень считать.
В кейсе, где автоматизируется НЕ бутылочное горлышко, вопрос не к автоматизации, а выбору цели. Причем здесь сама автоматизация?
-
Там, где нужно поправить параметры отчёта: если такого параметра изначально не было, аналитик потратит столько же времени на переработку отчёта. А если был, то автоматизация только в плюс
То есть, в общем, жёлтый заголовок, и порете вы хрень. Накидали бы вам минусов за такую вот спекуляцию.
qw1
25.12.2021 00:57+3По второму пункту, я считаю, всё верно. Стоит только автоматизировать какое-то действие или отчёт, пользователи моментально теряют способность делать это вручную. Если что-то ломается, ни в какую не согласны делать по-старинке: программисты — чините! Или если что-то надо изменить/добавить.
аналитик потратит столько же времени на переработку отчёта
Аналитик потратит больше времени, т.к. это не то, с чем он работает каждый день + надо хорошо формализовать + поставить задачу разработчикам. Зато один раз, а не каждый день.
Проблема в том, что функции перекладывают с рядовых менеджеров, которые раньше делали такой отчёт, на ИТ-отдел. При этом, новых людей в ИТ не добавляют. Считается, что если что-то автоматизировано, то работа сделана, и больше не требует внимания. Но каждый день накидывают новое. А оно всё копится и требует поддержки на самом деле.
Crystal_HMR
25.12.2021 01:23Ну у вас ведь есть система ведения отчетности о проделанной работе? Система трекинга времени? Если новые вещи не имплементируются или задачи выполняются долго - то нужно показать почему. Если отдел из N разработчиков тратит время на поддержку старых продуктов - то, к сожалению для них [разработчиков этого отдела], они должны доносить об этом руководству/заказчику. И либо нанимайте доп.персонал, либо откладываем реализацию новых фич и занимаемся рефакторингом старых проектов. Как правило, после рефакторинга оказывается, что как минимум третью уже никто не пользуется, еще третью пользуются единицы, а еще треть - это дублирующий функционал. Можно напрячься, сделать самим, нарисовать красивую презентацию о проделанной работе и прийти к руководству с запросом на повышение. В зависимости от развития событий - принимать соответствующие решения.
qw1
25.12.2021 10:57+2Учёт задач и трекинг времени работает внутри ИТ-отдела (т.е. к рядовым программистам вопросов нет), а уровнем выше не интересен никому. Видимо, у нас (и у автора статьи) проблема в том, что у ИТ-отдела не единый заказчик, которому можно показать и объяснить, а куча других департаментов. Каждый тянет одеяло на себя, желая, чтобы только его хотелки быстрее выполнялись (показать, что его департамент работает хорошо), и пофиг на общее дело.
Crystal_HMR
26.12.2021 11:35У ИТ отдела как правило не один заказчик. Но другие ведь справляются :)
Что бы понять чьи хотелки делать раньше - нужен некий скоринг заявок. Лучше, если этот скоринг будет делать бизнес. Если есть единый руководитель бизнеса - то в итоге он. Если нет - то пусть руководители бизнесов собираются и обсуждают друг с другом кто важнее.
А вот занятость разработчиков не волнует тех, кто сверху, пока руководитель разработчиков не может правильно донести до верхов текущую ситуацию.
Ventarron Автор
25.12.2021 09:54+2Вообще, обычно не отвечаю на хамские комментарии.
"Передернули", "порете хрень", "спекуляции" — фу таким быть.
Но я вижу, что другие люди ваш комментарий читают, поэтому отвечу для них, а не для вас. Тем более это позволит глубже раскрыть некоторые тезисы статьи.
-
Типичная история именно для автоматизации:
Увидели проблемы в операционке → Автоматизировали операционку
Вместо этого, я предлагаю действовать так:Увидели проблему в операционке → Оцениваем её в масштабе всего бизнеса → Автоматизируем только если это повлияет на наши ключевые метрики
Конечно, так оценивать нужно любую задачу. Но, на моей практике, ошибки допускаются чаще именно при автоматизации. Думаю, это связано с иллюзией экономии, которую она дает.
-
Аналитикам, с которыми я работаю, обычно нужно 5-15 минут, чтобы подправить SQL-запрос. За это время можно разве что оформить задачу на разработчика, но точно не сделать её, не проверить её и не вылить её.
Плюс разработчик же не делает задачу в вакууме — он делает задачу вместо какой-то другой, полезной задачи. Я всегда очень осторожно отношусь к тому, чтобы грузить разработчика чем попало.
P. S. Солидарен с комментарием qw1 выше. Видно, что человек уже сталкивался с подобными ситуациями на практике.
ciuafm
25.12.2021 12:20На удивление полезная статья, написанная вдумчиво и доходчиво. Я сам сторонник спонтанной автоматизации - вжух-вжух и в продакшн. Меня постоянно сдерживали понимающие начальники, но только сейчас, прочитав эту статью, я понял почему они это делали, хотя они и пытались объяснить. Рекомендую к прочтению сисадминам - автоматизаторам которые работают соло.
Ventarron Автор
25.12.2021 12:27Спасибо большое за этот комментарий!
Признаться, мне нелегко дается написание статей. Конкретно для этой я около года делал заметки и собирал кейсы, а потом пару месяцев шлифовал текст.
Но когда вижу такие комментарии, то кажется, что всё было не зря :)
-
Pasquil
25.12.2021 02:04+5Прошу прощения, но что-то какой-то странный продакт в вашей статье... Скорее местечковый проджект, без руководителя, на подхвате. Этакий проджект, не обременённый моральными принципами.. И в компании, видимо, не знают о такой вещи, как стратегия, которая включает в себя не только развитие бизнеса, но и развитие внутренней инфраструктуры.
Как вообще можно брать в работу проект без, хотя бы, предварительной оценки? Если разработчики тратят 50 "фантиков" на поддержку автоматизации, то может проблема в постановке задач? Или в костылях?
При всем этом, вы пишете и правильные вещи. Ну, которые прописные истины. Ощущение, что ваш продакт из статьи, далеко не матерый, а работает примерно 1-2 года и просто описывает свой путь проб и ошибок. Это не плохо, но статья должна называться по-другому в этом случае. А язык написания вполне хорош. Мне понравилось. Читается достаточно легко.
А пример с отчетом и Олегом шикарен... Если в течении года автоматизация помогает получать нужный отчет и только один раз в год нужно изменить настройки выгрузки - явно не стоит держать для такого отчета человека в штате.
И да, автоматизация может привести к увольнению сотрудника. А может и к перераспределению функционала. И тот и другой вариант работодателя устраивает. Вы же работаете не на коллегу, чьи действия можете автоматизировать, а на компанию?
Я ни в коем случае не сторонник увольнения всех и вся. Для меня интереснее освободить человека от рутины и дать ему другие задачи.
В общем, к чему я все это. Вредит не автоматизация. Вредит отсутствие проработки и понимания для чего это все делается и к чему приведет.
Ventarron Автор
25.12.2021 09:08Предполагаю, что ваш опыт из другой области — возможно, вы работаете в аутсорсе? Я же говорю о работе над собственным продуктом. В любом случае, постараюсь ответить по пунктам.
Почему проджект? Разве проджект проектирует автоматизацию, общается с заказчиками, продумывает кейсы, пишет техзадание? У него ж совсем другая роль. Конечно речь о продакте или хотя бы бизнес-аналитике.
Смотря что вы имеете в виду под оценкой проекта. Если эстимейт задачи разработчиками — то, конечно, все оценивают размер задач, это обычная практика. Если же речь о финансовой оценке окупаемости каждой фичи или гипотезы — то это встречается довольно редко, только в компаниях с сильной продуктовой экспертизой.
Не очень понял вот это сочетание: "местячковый, аморальный и с опытом до 2 лет") Откуда такая статистика? Я собеседовал достаточно продактов из крупных городов и компаний, и вот что могу сказать: продакты с опытом до 5 лет очень редко умеют делать автоматизацию грамотно (не наворотить космолет, учесть все кейсы, качественно опросить заказчика и т.д.). В Белоснежку продакт превращается где-то на границе 5-7 лет опыта. Но, понятно, всегда есть исключения.
Конечно, никто не держит аналитика ради одного отчета. Но типичная ситуация, когда в обязанности аналитика, помимо всего прочего, входит и несколько регулярных выгрузок из БД.
С последним вашим тезисом "Вредит не автоматизация. Вредит отсутствие проработки и понимания для чего это все делается и к чему приведет" - согласен. Но как раз в этом и задача статьи — дать понимание "как повлияет автоматизация" тем, кто ещё не совсем это понимает :)
onlinehead
25.12.2021 15:18+1Если же речь о финансовой оценке окупаемости каждой фичи или гипотезы — то это встречается довольно редко
Эм, а на каком основании тогда вообще принимается решение о разработке фичи или анализе гипотезы? Как можно вообще начать что-то делать, не понимая хотя бы в первом приближении кому это нужно и во сколько это обойдется в дальнейшем?
Не, я понимаю если речь идет о хобби-проекте, но как это с бизнесом то соотносить?Ventarron Автор
25.12.2021 18:18+2О-о-о, вы бы удивились какой бардак творится в вопросах приоритезации бэклога!
Я довольно регулярно собеседую продактов — в основном мидл+ и синьор уровней. И, чтобы понять как они мыслят, всегда расспрашиваю — как они генерили гипотезы, как их приоритезировали и т.д.
Так вот даже в крупных компаниях часто берут в работу задачи, потому что "СЕО настоял", "команда очень хотела", "пользователи пожаловались", "конкуренты такое сделали", "оунер очень верил в эту идею" и т.д. В лучшем случае используют RICE или ICE методологии. Но реальную приоритезацию на основе прибыли, с учетом маржинальности, с расчетом срока окупаемости — такое делают единицы.
А самая дичь творится в госкорпорациях, там люди вообще не понимают слова "окупаемость". Мыслят категориями "освоить бюджет" и "руководитель так сказал". Я такого наслушался, что до сих пор кошмары снятся))
lxsmkv
25.12.2021 09:11+5На фоне возрастающего спроса на RPA (robotic process automation), весьма ожидаемый отрезвляющий пост.
Я думаю что, грубо говоря, один специалист по Lean Management даст быстрее рост производительности, чем автоматизация без разбору.
Кстати, в применении к автоматизации тестирования, похожая картина. Автоматизация пилится, баги находятся, баги регистрируются, но клиентом не приоритизируются. Ну и нахрена автоматизация, если ты этой информацией по сути не пользуешься. Зачем ускорять накидывание багов в джиру? Чтобы потом через шесть месяцев выяснить что баг был починен случайно, в связи с чем-то другим. Т.е. автоматизация сама по себе, спринты сами по себе. Такая петрушка бывает, когда клиент заказывает автоматизацию тестирования, но не совсем понимает для что он собирается с ней делать. Он требует повышения покрытия, отчетов, собирает всевозможные метрики, а баги из автоматизации как лежали в багтрекере полгода назад так и лежат.
Еще, по моему опыту, люди упорно не хотят устранять очевидные препятствия. Они будут "спотыкаться о швабру", материться, эта швабра станет притчей во языцех, но не станут ее убирать на место. За наведение порядка во внутренних процессах клиент не платит, поэтому на это "времени нет". Так и будет валяться в бэклоге таск, что надо перестать делать миграции базы данных скриптами и принятъ на вооружение Liquibase. И тому подобное. Даже если есть свободное время, никто пальцем не пошевелит. И, что интересно, по моим наблюдениям, можно быть хорошим специалистом и при этом "не видеть" все эти потери эффективности. Наверное именно потому, что профессионалу "ничего не стоит" состряпать миграционный скрипт, или подправить что-то где-то руками в сотый раз. Ведь это как бы не так часто происходит. А если еще и менеджер человек заботящийся в первую очередь о закрытии обязательств перед заказчиком (читай "прикрытии своего тыла") то оно так и будет гнить потихонечку.
Javian
Вспоминается начало 2000-х, когда в школах пытались учить VBA т.е. предполагалось, что компьютерная грамотность - это умение программировать в Excel. Каждый должен был бы уметь автоматизировать свою работу.
Ventarron Автор
Ну это, кстати, хороший кейс, когда кто-то может самостоятельно свою работу автоматизировать.
Я когда-то, в позапрошлой жизни, был верстальщиком в еженедельной газете. А верстальщик, работавший до меня, тратил по несколько часов на финальное форматирование текста (всякие отступы, кавычки, выделения, стили). Довольно муторная скучная работа, которая требует большой внимательности. После такого глаза гарантированные красные. И так каждую неделю. И нет права на ошибку, т.к. потом газета отправлялась в типографию и печаталась тысячами экземпляров.
Помнится, я написал какой-то несложный скрипт, который делал всё это форматирование автоматически, за несколько минут. Об этой автоматизации я не пожалел))
Robur_le_Conquerant
Главное, чтобы о такой автоматизации бизнес не узнал. А то скажет "мы брали тебя на 8 часов в день, а ты отрабатываешь теперь только 2. Остальные 6 часов ты автоматизировал. Будем платить за 2. А за автоматизацию спасибо. Ты молодец"
kompilainenn2
После такого можно скрипт снести без следов и искать иную работу
Zeiram
Вместо Работы вы сделали Автоматизацию Работы - вы проявили инициативу и эта деятельность не была оговорена с шефом заранее. Значит вы поступили не как наёмный сотрудник, а как совладелец бизнеса. По-сути вы дали бизнесу сильно больше того, что предполагалось, причём бесплатно. Вам дали внеочередную премию или какой-то бонус?
Моя интуиция подсказывает, что не дали. Ведь так у нас заведено - бесплатное принимается, но не ценится.
PereslavlFoto
Бонус дали: время и здоровье.
Но в целом вы, конечно, правы. За такие действия надо доплачивать. Беда в том, что если вообще нужны такие действия, если ситуация провоцирует такие действия — значит, денег у компании нету. Будь у неё деньги, она бы уже наняла умельца и загодя такое сделала.
Crystal_HMR
На моем опыте чаще компании (или руководители подразделений в больших компаниях) даже не знают о такой возможности. А потом "а что, так можно было?". И тут несколько исходов. В первом случае вас поблагодарили, стали относиться лучше, стали давать похожие задачи и всячески мотивировать. Бывает, что ничего не меняется кроме осознания, что у вас больше времени свободного и давай ка мы нагрузим вас всякими другими задачами (армейский вариант: кто не курит - тот копает). Честно говоря, ни разу не видел вариантов с увольнением после таких ситуаций, но не отрицаю, что такое может быть. Со мной лично была ситуация, что написанное мною требовалось при увольнении с мотивацией "это делалось в рабочее время на рабочем оборудовании" и не взирая на то, что все вокруг имеют такое же рабочее время и такое же оборудование, но делают это руками (не говоря уже о том, что работы много, и делал я это дома по вечерам). Бывшему руководителю я сказал, что всё снёс и это не вернуть, но заинтересованным исполнителям копию из бекапа восстановил после личной просьбы.
Ventarron Автор
Ну мне тогда было двадцать с чем-то лет, я такими критериями не мыслил. Все было проще — работать неудобно, сделаю удобнее :)
Из бонусов я тогда заработал только респекты от коллег.
Ну и как верно написал Crystal_HMR, в редакции до этого никто и не предполагал, что этот процесс вообще можно автоматизировать.
nikolayv81
Главное чтобы потом не получилось как в одной крупной на тот момент бумажной газете "известия", когда в ней в статьях стали регулярно проскакивать "служебные тэги", в районе 2002го гдето...
Ventarron Автор
Ну это, кстати, хороший пример и подтверждение тезиса, что нельзя "раз и навсегда" сделать автоматизацию и просто забыть про неё :)
Javian
Не так давно
fo_otman
Так уж получилось, что я начал свой путь программиста с составления программок на VBA в Excel. Через полгодика кропротливого изучения был на работе полубогом. Ужасные, кривые, но рабочие скрипты очень-очень облагчали людям жизнь. Ощущение удовлетворенности от работы было на 120%.
PereslavlFoto
Но почему же они были ужасные и кривые?
fo_otman
я несильно парился над всякими дурацкими принципами и дублировал код столько раз, сколько надо было.