Суррогат – это когда сделали не то, что нужно бизнесу. Или не так, как нужно бизнесу.
Суррогаты – это самое страшное зло, происходящее сейчас с российским бизнесом и государственным управлением. Суррогаты – это лучший в мире киллер эффективности. Что особенно приятно, мы, программисты, на этот раз не в стороне – мы на самой оси зла.
С чего все начинается
Представьте исходную ситуацию. К программисту, работающему в «обычной» компании, подходит человек – пользователь системы, он же – руководитель некоего подразделения. Просит, или предлагает, или просто нейтрально говорит – надо сделать в программе/системе/на сайте такую-то штуку.
Программист, допустим, толковый – он понимает, что предлагаемая доработка – суррогат.
Вариантов развития событий много, я приведу некоторые из них:
1. Программист говорит: согласуй с моим или своим начальником, тогда сделаю;
2. Программист говорит: напиши мне задачу/поручение/служебную записку, на бумаге или в информационной системе;
3. Программист говорит: нужно мнение вот этого и вон того человека, т.к. их интересы доработкой тоже затрагиваются;
4. Программист говорит: твоя задача – суррогат, и добавляет что-нибудь из первых трех пунктов;
5. Программист просто говорит: не буду делать;
6. Программист говорит: задача бесполезная, или даже вредная, я сейчас всем скажу и докажу, что ты – дурак;
7. Программист говорит: надо запускать внутренний проект, давай все согласовывай и организуй, и сделаем.
Все перечисленные варианты ответа объединяет одно – результат. В большинстве случаев это будет произведенный суррогат.
В описанной ситуации программист ведет себя так, чтобы суррогат точно, обязательно и бесповоротно был создан.
Если сказать об этом программисту, он будет возражать, яростно возражать. Вот вы же возражаете? Или вообще уже перестали читать и убежали в фейсбук.
А почему?
Если вы еще здесь, то давайте разбираться, что не так с поведением. Попробуйте перечитать исходную ситуацию и варианты поведения программиста. Что объединяет перечисленные паттерны? Как поведение программиста качественно меняет исходную ситуацию?
Ответ прост – все варианты включают (в смысле нажимают ВКЛ) публичность. Кроме программиста и пользователя появляется третий, четвертый, десятый человек.
Публичность заставляет человека защищаться, отстаивать свои предложения, настаивать на их реализации. Просто потому, что задевается его чувство собственной значимости и авторитет.
Во многих компаниях корпоративная культура – консервативная и патриархальная. Там полно паразитов, много имитации бурной деятельности, мало фактов с цифрами и много подковерной возни, которую принято называть политикой.
Немного политики
Что самое опасное, вредное и смерти подобное в политике?
Вот вы ведь наблюдаете, хотя бы иногда, за политикой в стране и в мире. Что, по вашим наблюдениям, политики делают реже всего?
Признают свои ошибки.
Признание своих ошибок – это политическое самоубийство. Кто угодно может говорить о конкретном политике что угодно, обвинять его во всех смертных грехах, приводить доводы и факты. Но политик никогда не признает свою ошибку.
Максимум, которого можно ожидать – ошибку признает не сам политик, а его подчиненные, желательно пониже рангом, и тихонечко, шепотом, обтекаемо, чтобы не навредить хозяину.
В корпоративном мире действуют те же законы.
Авторитет, карьера, зарплата, перспективы человека зависят от политических баллов.
Ад своими руками
И вот программист, видя потенциальный суррогат, бьет в самое больное место – публичную (=основную) жизнь политика. Суррогат выставлен на всеобщее обозрение, и табличка повешена: «Программист сказал, что это суррогат».
Человеку ничего не остается, кроме как всеми силами защищать свое политическое лицо, действуя в двух направлениях: убедить всех, что суррогат – не суррогат, а заодно устроить все так, чтобы программист оказался дураком.
Второе направление – это путь паразита. Раз уж программист выполз из своей норы и решил потягаться с серьезными людьми, надо создать условия, при которых он не сможет выполнить задачу или проект.
Кто не помнит, освежу: паразит – это тот, кто старается сделать так, чтобы задача не была решена. Прям применяет определенные действия для этого, задачу ставит так, чтобы не решилась, сроки ставит неправильные и т.д.
Это вообще оптимальный путь, убивающий сразу двух зайцев – и суррогат не воплотился (а значит, никто не проверит, был ли он таковым) и программист в дураках, т.к. не решил задачу.
Что неприятно, коллеги этого пройдохи пойдут тем же путем, т.к. паттерн оказался удачным. К программисту больше никто не будет приходить и спрашивать его мнения – задача сразу будет ставиться публично, чтобы суррогат был произведен с высокой вероятностью. А если не произведен, то хотя бы за счет программиста поднять свой политический рейтинг.
Тут уже работает другой феномен корпоративной культуры – кто первый говорит о проблеме, тот – молодец, получает пятерку, пополняет свои политические баллы. Такого народу и в бизнесе, и в жизни – тьма тьмущая.
«Хьюстон, у нас проблемы!» — и ждет свой лайк от руководства. Лайк пополняет баллы. Будет проблема решена, не будет – вообще не важно. Главное проблему найти и первым о ней заявить.
Кто нашел проблему, тот вроде и решать ее не обязан. Все вокруг обязаны. Особенно программисты.
Любой толковый паразит сходу назовет вам 10, если не 50 проблем в информационной системе, в которых виноват программист, только повод дайте. Тут и понимать-то особо ничего не надо, достаточно сказать «тормозит», «отваливается», «из дома не могу работать», «с планшета не могу работать», «CRM плохой», «интерфейс корявый», «блокировки какие-то».
Ох, увлекся. Эта тема – разозленный политический паразит – не центральная в публикации. Она – следствие публичной демонстрации суррогата.
Итак, вот он ад во всем своем великолепии. На каждом совещании все наперебой говорят: автоматизации нет, задачу программисту поставили, а он ничего не делает, а у меня эффективность низкая без этой доработки, бла-бла-бла.
Я через такое проходил. Мне буквально мстили, ставя задачи. На каждом совещании – вот, я поставил ему задачу, требую назвать срок решения, я крутой управленец, а в ИТ бардак, я бы нанял внешний франч лучше, у меня еще 100500 задач для ИТ.
Политическая карьера человека, который говорил эти фразы чаще других, резко и быстро шла вверх. Я до сих пор удивлялся, как это возможно при столь скромных способностях.
Теперь, конечно, понимаю, что это, во многом, моя заслуга. Я в свое время очень активно выводил в публичное пространство все потенциальные суррогаты, руководствуясь благими намерениями.
В эффект получил обратный – суррогатов не только стали больше предлагать, но и их почти все пришлось реализовать, моими силами. Доходило до того, что мое мнение вообще игнорировалось всеми участниками процесса. И был дан прямой приказ – делай все, что говорят.
А начиналось все с малого – с публичности, с выноса сора из избы.
А решение есть?
Решений полно, вы сходу назовете несколько. Если не назовете, то предлагаю на выбор те, что использовал я. На высшую истину не претендую, универсальность не гарантирую, только для теоретического изучения.
Конкретно моя ситуация разрешалась удачно, и не один раз, а целых три, и всегда разными путями.
Путь бизнес-программиста
Первый путь – сложный, но в плане саморазвития очень полезный – разобраться в смежных областях и делать изменения самому, от начала до конца. Выявлять проблемы, формулировать задачи, придумывать решения, реализовывать их и внедрять. Это классический путь бизнес-программиста.
Суть пути – разобраться в работе других и быть проактивным. Второе важнее.
Проактивность измеряется легко. Проактивный бизнес-программист ставит себе задач больше, чем получает извне.
У меня процент задач и проектов, запущенных в работу по моей инициативе, доходил до 80-90.
Людям вокруг просто нечего было предложить для автоматизации, т.к. я все уже предложил. Оставались, в основном, мелкие задачи, с которыми я даже не спорил – просто выделял им определенный процент времени в неделю.
Путь бизнес-программиста решает проблему производства суррогатов на корню. Если помните исходную ситуацию, то на пути бизнес-программиста она просто не случается – никто не приходит и не просит и не требует чего-то автоматизировать.
Путь Главного
Этот путь встречается редко, но для полноты картины я его упомяну.
Путь бизнес-программиста привел меня на место Главного по стратегическим изменениям в компании. Говоря простым языком, все изменения в бизнес-процессах, автоматизации, стратегиях и т.д. были в моем ведении.
Тема стратегических изменений компании силами программиста – большая и интересная, но не особо относится к данной публикации, поэтому детально раскрывать не буду.
Главное, что важно в контексте суррогатов: когда ты Главный по изменениям, ты можешь смело посылать всех, кто принес тебе суррогат. Что я, собственно, и делал.
Путь Спарты
Путь Главного по изменениям привел меня к третьему, компромиссному и самому, на мой взгляд, жизнеспособному пути.
Есть такая методика, которая формулируется как «fail fast, fail cheap». Переводится как «проваливайтесь быстро, проваливайтесь дешево».
Эти принципы были разработаны в ИТ-среде, вроде бы в веб-разработке, и тесно связаны с гроузхакерами (growth hackers). Углубляться не буду, уже упоминал этих ребят несколько раз в других публикациях, у них есть чему поучиться. Они очень похожи на бизнес-программистов.
Кстати, Agile, которым повально увлекаются
Возвращаемся к fail fast и суррогатам. Ключ в том, чтобы любое решение было сначала прототипом, предназначенным для проверки пригодности, и только потом становилось железобетонным, официальным и прописанным во всех инструкциях.
Fail fast это:
• Быстро решили, делать или нет;
• Быстро сделали прототип, самым коротким путем;
• Быстро запустили в работу, на ограниченном круге самых адекватных лиц;
• Быстро сняли результаты;
• Быстро приняли решение – это fail или success;
• Если fail – выкинули на помойку;
• Если success – довели до ума (интерфейсы, производительность, обучение, инструкции, бумажки).
Теперь должно стать понятно, почему fast превращается в cheap (дешево). Потому что если делать «как обычно», то выходит значительно дороже. Сами знаете, как выглядят затраты на автоматизацию по принципу Парето. Fail fast использует те самые 20 % времени, пропуская 80 % до принятия решения о судьбе изменения.
Заметили, что fail fast очень похож на Agile? Эти штуки не заменяют, а хорошо дополняют друг друга.
Но главное, в контексте данной публикации – fail fast не пропускает суррогаты, не оставляет их в живых.
Помните, где такое было? Когда рождался мальчик, как и всех спартанцев, его внимательно осматривали. Если он был слишком мал, тщедушен, болен или уродлив, от него избавлялись. Это такой fail fast по-спартански. Или генетика, если хотите.
Как осуществить fail fast на практике, в нашей исходной ситуации?
Конечно, идеальная картина – когда все вокруг понимают, что такое fail fast, и он является нормой корпоративной культуры. Знаю, что у вас такого нет и не будет. У нас такого тоже не было и не будет. Но упомянуть стоило, вдруг вы, дорогой читатель, из другой страны.
Главный переключатель в fail fast – не включать публичность.
С публичностью никакого прототипа не получится. Вы будете делать все, что скажут, «от заглавной буквы У до тиража и типографии».
Нужно дать понять человеку, который к вам пришел, что ваша задача и цель – помочь ему, в т.ч. в политической борьбе. Призвать к непубличности этой автоматизации, объяснить почему предлагаете действовать именно так.
Если получится – отлично, сходишь и объявишь, какой ты молодец. Получишь свой лайк. Меня упомянешь, если есть желание (упомянет, будьте уверены).
Если не получится – никому не скажем, никто не пострадает, не нужно будет оправдываться и защищаться.
Ну и совесть перед собственником будет чиста, мы ведь не потратим много времени и денег. В случае ошибки потратим намного больше и, что значительно хуже, взвалим себе на плечи новый балласт – никому не нужный суррогат.
Если отношения с человеком неплохие, то можно даже смелее сказать: я знаю, что ты предлагаешь ерунду, но на словах я тебя убедить не смогу, давай сделаем прототип и ты убедишься. Или я пойму, что был не прав (эту фразу лучше ввернуть, чтобы была постелена соломка).
Ну и действовать. Максимально непублично. Это очень важно, и вот почему.
Даже если вы вдвоем отличные парни, понимаете что делаете и обо всем договорились, в компании всегда найдутся люди, которые захотят заработать политические баллы за ваш счет. Теперь уже не за счет лично вас, а на всей вашей уютной fail-fast-компашке.
Работа по fail fast – это почти всегда нарушение регламентов и процедур, потому что ничего не согласовывается, не оформляется, в график не включается.
На этом вы со своим новым дружбаном и можете погореть – на формальностях, точнее на их несоблюдении. Пострадаете оба, и дружба кончится – придется защищаться и оправдываться, чтобы восстановить свое положение. А виноват будет программист – он же fail fast предложил. Ну и второй раз подружиться уже, скорее всего, не получится.
Особое внимание надо обратить на дружбана – он первый, кто побежит хвастаться вашей непубличной работой по «современной методике менеджмента» fail fast. Понимаете, почему? Потому что он на этом политические баллы заработает.
У меня были такие случаи несколько раз, и если случался прорыв непубличности, то виноват всегда был один человек – тот, кто пришел ко мне со своими проблемами.
Работа по fail fast их так вдохновляет, особенно когда очень быстро появляются результаты, которые можно пощупать, что они не могут удержаться – бегут к коллегам, к руководству и начинают продавать свой еще не полученный результат, в обмен на лайки.
Результат всегда один и тот же – внимание руководства и завистников с формулировкой «а вы что там вообще делаете?». Ну а дальше по стандартному сценарию: а почему мой проект не делаете, а где согласование, почему пропущена стандартная процедура, где ТЗ, и т.д. Говоря проще, «почему не оформлен суррогат?».
Вы, как программист, понимаете, что такое fail fast. Вы применяете эту методику и интуитивно, и осознанно, каждый день. Написал, запустил отладку, проверил, двинулся дальше или переделал.
А в бизнесе так не умеют. Вы можете научить, и суррогатов станет меньше.
Комментарии (54)
zenkz
14.12.2017 01:45Немного критики:
— Не понравился термин «Суррогат». Суррогат — это ожидаемая вещь в плохом исполнении (как например кроссовки Abibas китайского дядюшки Лао). Здесь же идёт речь о разработке ненужных или вредных систем или улучшений. Я бы назвал это «хотелками». Не особо лучше, но чётче передаёт смысл.
— Второй момент который не понравился — вы позиционируете себя борцом с системным управленческим бардаком (типичным для больших компаний и госорганизаций), но играете уже по их правилам. Отсюда и публичность и лайки и прочие подковёрные игры.
Вот что бы я делал на вашем месте:
— Будьте нацеленными на результат. Ваша задача — улучшение бизнес-процессов путём автоматизации. Рассматривайте любую идею и пытайтесь её улучшить, чтобы она соответствовала ожиданиям
— Разговаривайте, старайтесь помочь — если к вам пришли с предложением, но не спешите клеймить её «суррогатом». Сядьте вместе с просителем и проговорите как процесс работает сейчас, зачем нужна автоматизация и какой ожидаемый результат. Вежливо указывайте на недостатки предлагаемого варианта и пытайтесь найти лучшее решение или компромисс. В этом случае никто не будет обиженным и устраивать вам пакости, а компания получит нужный ей продукт
— Проактивность — это хорошо, но я бы не бежал впереди паровоза. Т.е. если есть хорошая идея — ей нужо делиться и реализовывать, но и затыкать рот другим генерируя свои идеи как из рога изобилия тоже не стоит — всё-же вы не эксперт во всех областях. Иногда лучше подойти к человеку, который работает с системой и посидеть рядом с ним и посмотреть какие процедуры неудобны. Либо собирать предложения от пользователей.
— Будьте профессионалом — не участвуйте в подковёрной борьбе, а в случае вовлечения старайтесь из неё выйти.
— В вашем подходе fail fast, fail cheap есть 2 недостатка: с одной стороны он дорогой, т.к. время тратится на разработку того, что можно было бы не делать, с другой стороны он способствует написанию плохого кода, появлению костылей и вообще ведёт к некачественному продукту. Для меня первое правило разработки — делать так, чтобы потом не переделывать, т.к. обычно переделывать времени нет.alek_sys
14.12.2017 02:08Кстати, да, "суррогат" создало в целом скорее негативный фон для статьи, хотя тема важная.
Хочется заметить по поводу
"В вашем подходе fail fast, fail cheap есть 2 недостатка: с одной стороны он дорогой, т.к. время тратится на разработку того, что можно было бы не делать, с другой стороны он способствует написанию плохого кода, появлению костылей и вообще ведёт к некачественному продукту".
На это в современных lean практиках есть решения:
- дороговизна эксперимента (а вообще если убрать свою терминологию то это и есть lean experiment) решатся за счет практик Lean UX Design и User Centric Design, т.е. любое решение начинается с проблемы пользователя и через "дешевый" прототип (банальный wireframe) валидируется на пользователях, до того как уходит в разработку
- плохой код и костыли — TDD + CI + постоянный рефакторинг
nmivan Автор
14.12.2017 07:08Спасибо за развернутый комментарий.
Не понравился термин «Суррогат»
Здесь имелся в виду суррогат не ожидаемый, а подсунутый :)
Покупал как-то минералку на вокзале, оказалась вода с содой. Вот такой суррогат.
Или, из бизнеса — покупаем автоматизацию бизнеса с целью сокращения затрат, получаем повышение затрат, расширение бухгалтерии и штат программистов в придачу.
вы позиционируете себя борцом с системным управленческим бардаком <...>, но играете уже по их правилам
не совсем. Я, скорее, экспериментирую и пробую разные варианты — от следования их правилам, до их полного разрушения. Иногда, ради эксперимента, делаю вид, что я такой же, как они. Это как игра. В публикации отражены 4 состояния, через которые я проходил в этой игре — сопротивляться, работать за них, возглавить их, договориться с ними.
Лично мое мнение — ради жизненного опыта надо иногда поучаствовать в подковерных играх. Не настаиваю. Это увлекательно, если границы не переходить.
Для меня первое правило разработки — делать так, чтобы потом не переделывать, т.к. обычно переделывать времени нет.
У меня почти так же, я предпочитаю создавать и пользоваться абстрактными настраиваемыми инструментами, чтобы делать с их помощью быстрое прототипирование. Там обычно и кода-то нет, мышкой все натыкивается, или живет в БД как временный код и запросы.
spinacheyepressure
14.12.2017 07:41«Симулякр»?
Потому что воплощен в коде, выполняет в ИС какие-то действия, но при этом не оказывает положительного влияния на бизнес-процессы.
alek_sys
14.12.2017 02:00В современной практике продуктового дизайна "fail fast" называется Lead Product Development. Он неплохо описан в книге "The Lean Startup". Несмотря на название, там не только про стартапы и не только для стартаперов.
lxsmkv
14.12.2017 03:52Эээ… мне одному показалось, что суть текста: «Чтобы меньше переделывать потом, вовлекайте заинтересованных лиц в процесс разработки с самого начала, часто и регулярно.»?
nmivan Автор
14.12.2017 07:12Не совсем так. Речи о качестве кода здесь не идет, только о том, нужен ли продукт бизнесу.
Программист и его код в данной публикации — черный ящик, который либо делает продукт, либо не делает его.
sbnur
14.12.2017 06:31Вопрос — с вашей точки зрения — система управления Саяно-Шушенской ГЭС была суррогатом — ведь в конечном итоге в нужный момент система защиты не сработала
nmivan Автор
14.12.2017 07:15Суррогат или нет — определяется целями потребителя.
В вашем примере цели мне, увы, не известны.
Вот есть такая система — JIRA. Сама по себе она не плохая, не хорошая. Не суррогат и не то, что нужно.
Если ее вручить дворнику для повышения его эффективности, то JIRA станет суррогатом.
Потому что «нафига козе баян».sbnur
14.12.2017 07:54Думается в данном случае цель известна — управление агрегатами и предотвращение аварийных ситуаций.
Автоматика на ГЭС не сработала, что привело к катастрофическим последствиям.nmivan Автор
14.12.2017 08:00Сорян, не заметил, что вы про систему управления, а не про саму ГЭС.
Если авария произошла именно из-за системы управления, то — да, это суррогат.
Просили систему, которая защитит от аварии, получили систему, которая не защитила.sbnur
14.12.2017 09:10Более поздний пример — неудачный запуск с космодрома Восточный — там тоже был суррогат в качестве программного блока? — то есть до некоторого момента (прошлые запуски) все работало, но изменение условий запуска привело к неудаче.
Каков критерий отличия суррогата от нормального изделия — любая система может дать неудачи и не выполнить своих функций при стечении обстоятельств.
cuwHuk
14.12.2017 10:04Критерий отличия очень простой — отсутствие качественного обоснования необходимости данной фичи/продукта/..., зачастую обосновывается ссылками на какие-то мнения, попадание в мейнстрим (круто, клево, все так делают), просьбы мифических заказчиков, сулящих многомиллиардные контракты, и т.д.
Например:
— Приделайте ракете крылья.
— Зачем?
— Илон Маск, ворочаясь во сне, сказал, что будущее за ракетосамолётами.sbnur
14.12.2017 10:24В данном материале (см. выше) нет мифических заказчиков — есть некий заказчик-паразит, который просто хочет сделать изделие-суррогат — как определить паразита и как увидеть, что этот паразит хочет суррогат.
То есть разработчик лицо, заинтересованное в оплате своего труда — его мифические обещания не интересуют — точнее ему о них никто и не рассказывает — предлагается работа с соответствующим бюджетом — как определить. что проект своим контентом имеет суррогат. а заказчик представляет собой паразитаcuwHuk
14.12.2017 17:30Жизнь исчерпывается статьей? Я просто привел пример типового обоснования. Если разработчика интересует только оплата труда, то зачем ему вообще запариваться на тему суррогатов? Сделал — деньги получил, возникли вопросы — показал пальцем на паразита. Лично меня как разработчика интересуют не только деньги, поэтому тема статьи мне интересна, я с этим сталкиваюсь на практике и отфильтровываю паразитов по указанному признаку невозможности качественно и количественно обосновать необходимость решения задачи.
piup
14.12.2017 06:43«Дадим пользователю не то, что он хочет, а то, что ему надо!»
©)
KamiSempai
14.12.2017 15:17Что забавно, некоторые пользователи действительно не могут здраво осмысли собственную проблему и понять, что им на самом деле надо. И хотят они совершенно не того.
Bookvarenko
14.12.2017 06:47Так вот доходчиво и компактно оформлен багрепорт и сформулированы воркэрауды что даже я понял. Спасибо! Это настолько всё элементарно оказалось, а я столько нервов пожёг, эх…
habradante
14.12.2017 10:48Я обычно сразу спрашиваю «какую проблему решаем?» и еще несколько почему и зачем. Если на все эти вопросы получен ответ и проблема действительно решается так, как предлагает коллега, то можно двигаться дальше. Если проблема несущественна или решается легче другими средствами, то честно предлагаю решить ее проще и дешевле.
Обычно, люди способны понять, когда они из пушки по воробьям собираются стрелять, и вопрос снимается.
Если не понять в чем проблема, то «суррогаты» будут появляться регулярно. Если вы такой бизнес-программист, то надо разбираться в чем проблема, а не перехватывать инициативу по появлению суррогатов.
zharikovpro
14.12.2017 12:41> А почему?
А потому что рыба гниет с головы и за это платят. И вы описываете работу бизнес-аналитика, как минимум. Менеджера/директора а дополнение к нему как максимум.
> А в бизнесе так не умеют.
Умеют, но не везде. Бизнесы есть разные. Мой личный опыт показывает корреляцию: чем успешнее бизнес, тем лучше умеют, и наоборот. Возможно и так, что чем лучше умеют, тем успешнее бизнес.
Scf
14.12.2017 12:53Как идея с прототипами работает на практике? Проблема "суррогатов" не в том, что бизнес-заказчику будет неудобно им пользоваться — ему как раз будет удобно. Проблема в том, что любая качественная система построена на некотором дизайне, некоторых фундаментальных ограничениях. Например, "не давать прямой доступ в базу другим приложениям" или "не запускать аналитические запросы на OLTP базе".
"суррогат" именно этим и опасен — тем, что разрушает архитектуру системы, усложняя поддержку и уменьшая быстродействие. И коварен тем, что со стороны бизнес-заказчика это выглядит "программист не хочет работать".
Согласен с автором про публичность — если человек приходит к тебе с проблемой, нужно понять человека и проблему, а не создавать ему дополнительные трудности, чтобы он не создал трудности уже вам. И, в идеале, не кодить функционал, а решать проблемы.
Я считаю, что путь "бизнес-программиста" идеален. Человек, называющий себя сеньором, должен знать не только что он пишет, но и зачем и для кого. Куча плюшек за простое желание учиться.
Но как прототипирование может в этом помочь — непонятно.
nmivan Автор
15.12.2017 07:56Посмотрите чуть шире на прототипирование.
Бизнес-программист — это не программист для бизнеса, а программист бизнеса. Модифицирует бизнес-систему, состояющую из информационной системы, бизнес-процессов, системы мотивации, системы управления, целей.
В его ведении — вся система.
И прототипирование у него шире. Например, он может сделать прототип системы мотивации, погонять ее в тестовом режиме 3 месяца, и если при приемлемых затратах она даст прирост эффективности, то доделать и внедрить, в т.ч. автоматизировать.Scf
15.12.2017 09:27+1У вас какой-то замгендира получился, или как минимум начальник отдела.
nmivan Автор
15.12.2017 10:07Подозреваю, что вы сейчас рассуждаете с использованием штампов.
Умный, разбирается в бизнес-системах — значит гендир или его зам.
Умный, разбирается в системах мотивации — значит HR-директор.
Умный, понимает стратегию и оценивает следование ей — собственник, или как минимум гендир.
Это все значки, как у бойскаутов. Просто позиция в системе, на которой стоит человек. Позиция о человеке ничего не говорит — только то, что он смог ее занять.Scf
15.12.2017 10:18+1Я сейчас рассуждаю с использованием полномочий. Кто может модифицировать ключевые бизнес-процессы? Систему мотивации, завязанную на бюджет. Систему управления и, тем более, цели организации?
nmivan Автор
15.12.2017 11:04Полномочия — еще более условная сущность, чем должность. Полномочия даются и забираются элементарно, иногда просто кивком головы. И куча возможностей внутри компании, для использования которых вообще не нужны полномочия.
aquamakc
14.12.2017 13:34+1Отличная статья, спасибо.
Есть только один нюанс — разработанный по fail fast методике «прототип» лёгко и непринуждённо действиями менеджера может превратиться в «уже созданный продукт, готовый к внедрению». И может быть уже даже «продан».
В следствие чего программисту приходится чуть-ли не ночевать на работе подпирая костылями тот самый прототип, чтобы он хоть как-то выполнял весь разрекламированный менеджером функционал.
sshmakov
14.12.2017 15:53У автора про это тоже есть, начиная со слов
Главный переключатель в fail fast – не включать публичность.
С публичностью никакого прототипа не получится. Вы будете делать все, что скажут, «от заглавной буквы У до тиража и типографии».
aquamakc
14.12.2017 16:00+1В моём сценарии в публичное поле ситуацию выводит менеджер заполучив в обход регламентов «прототип» от разработчика и видя прекрасный шанс продемонстрировать свою полезность. Пока разработчик занимается своими делами, веря, что прототипом доказал менеджеру «суррогатность» его идеи — этот самый менеджер уже может влетать в кабинет ГЛАВНОГО, размахивая этим «прототипом» и докладывать, что «под его чутким руководством в личное, внерабочее время была произведена супер-штука, которая принесёт компании 100500 денег. Разработана, проверена, протестирована и можно уже завтра начать поставлять клиентам».
nmivan Автор
15.12.2017 07:49разработанный по fail fast методике «прототип» лёгко и непринуждённо действиями менеджера может превратиться в «уже созданный продукт, готовый к внедрению»
Да, такой риск есть. Второй раз с таким можно не работать по-пацански.
Либо — иметь такой же выход наверх, как и он. Чтобы присутствовать при «продаже».
lasalas
14.12.2017 16:03К программисту, работающему в «обычной» компании, подходит человек – пользователь системы, ...
По-хорошему, пользователю вообще не о чем разговаривать с программистом.
Но ситуация типичная:
— Бизнес-аналитик? Системный аналитик? Нет, не слышали!..
nmivan Автор
15.12.2017 07:47Верно. Я в жизни мало встречал бизнес-аналитиков, а те, которые попадались, подходили под определение «на, Боже, что нам негоже» — люди, не нашедшие себе места в жизни. Такие превращались в маркетологов, менеджеров СМК, или аналитиков.
lasalas
15.12.2017 09:07+1Увы, это так. Беда в том, что у российского бизнеса нет понимания ценности анализа самого по себе, вне контекста автоматизации. Нет понимания, что формализованное, отделенное от носителей и очищенное от различных ad-hoc-ов описание бизнес-процессов и алгоритмов не только является хорошой страховкой от случайностей, но и позволяет провести оптимизацию бизнеса и гораздо более качественную его автоматизацию. В результате, анализом занимаются случайные люди или вообще обходятся без него и вместо продуманного применения лучших практик, получаем хаотичное внедрение «хотелок» ?к?о?н?ч?е?н?ы?х? конечных пользователей.
michael_vostrikov
14.12.2017 16:21Ну и действовать. Максимально непублично.
Вы описываете сценарий, когда программист один на всю компанию, сам себе начальник, и его работой мало кто интересуется. И который к тому же не сильно загружен, раз у него есть время на посторонние проекты.
Если у вас есть начальник и ИТ-коллеги, вы не должны ничего делать без оформленной в каком-то виде просьбы. Хотя бы комментарий от бизнес-пользователя в таск-трекере. Именно потому что "Ну а дальше по стандартному сценарию: а почему мой проект не делаете, а где согласование...". Особенно если из-за ваших действий что-то не работает.
Причины изменений должны быть документированы, хотя бы для другого программиста.
Если success – довели до ума
Нет. Если success — выкинули прототип и написали заново.
sshmakov
14.12.2017 16:28Путь бизнес-программиста и Путь Спарты — они положительные, ориентированы на выполнение работ и достижение результата, пусть не того, что предполагался вначале.
Путь Главного — негативный, запрещающий какую-либо работу, очевидно не ведущую к озвученному результату. Только статус Главного предохраняет его от последствий из раздела «Ад своими руками», но это может оказаться временно — придет новый гендир и ему расскажут, что-де такой-сякой ретроград запрещает новаторство, которое могло поднять наш бизнес до небес.
Тут уже работает другой феномен корпоративной культуры – кто первый говорит о проблеме, тот – молодец
Не только корпоративной. Этот «феномен» также работает в уголовных деяниях, например, на взятках — кто первый настучал, тот законопослушный гражданин.
Fen1kz
14.12.2017 16:44ИМХО слишком много взваливаете на программистов. Можно провести аналогию — бизнес=здание, управленец=архитектор, прораб=программист. И вот архитектор подходит к прорабу и говорит «надо нам флигель приделать». И что, прораб будет такой — блин, зачем вам флигель, он не нужен бизнесу! Нет, его задача — сделать качественно. А то что им потом никто пользоваться не будет и он парковке мешать будет — уж простите, это не задача прораба. И уж если они (архитектор и прораб) такую хрень сделали, то вот прораб, пусть и исполнитель, но уж точно не «ось зла».
+ Мне не понравилось то что автор против публичности. Вот например у меня как у технаря вообще нет шансов в непубличных подковерных играх с управленцами, no way. Так что если они намереваются сделать фигню, то я как раз таки буду требовать максимальной публичности, да, все как расписали. Но я считаю, что это правильно. Если один я стабильно принимаю лучшее решение чем 20 человек — тогда зачем они вообще нужны / почему они что-то решают?
+ fail fast это ловушка и пропаганда говнокода как оно есть. Был я на таком проекте, двух ребят попросили «быстро сделать просмотровик свг тупо посмотреть как конвертируется». Ага, спустя 2 года ещё оставались куски jquery и кривой движ. И это не оттого что они плохие программисты, нет. Это оттого, что они делали «быстро посмотреть свг», а получился полноценный редактор. Если вы начали строить водоочистительную станцию, а оказалось что её водонагревательная функция для бизнеса важнее — у вас получится хреновая водонагревательная станция. Ну или без аналогий — если fail fast продукт взлетает, то никто не будет говорить — стопе, щас берем и все переписываем заново
Вообще вся статья это просто жесточайшее продвижение принципа «эй, вася, сделай по-быстрому мне прототипчик, потом переделаем если надо». Вот правда, так и вижу светлое будущее по автору:
С: Вааась, накидай побыстрому приложение для покупки слонов
В: Семен Палыч, а где ТЗ?
С: Какое ТЗ, прост типа 2 кнопки «купить слона» и «посмотреть слона» и все, тут работы на пару минут? Вон маша нарисовала тебе, держи.
В: (не обсуждать публично надо оно или нет чтобы не ударить по политическому имиджу С) оке.
*тык тык тык*
С: Отлично, теперь добавь туда профиль пользователя. Пару дней хватит?
В: *тык тык тык*
С: Супер, теперь допили туда музыку и магазин приложений!
В: *выдает ужасного слоноподобного монстра и вешается на рабочем месте*nmivan Автор
15.12.2017 07:43ИМХО слишком много взваливаете на программистов
не взваливаю, а предлагаю расширить зону ответственности, компетенции в смежных областях, выйти на другой уровень, работать с другими задачами, зарабатывать другие деньги.
Но решает каждый сам, разумеется.
Durimar123
14.12.2017 18:29Давайте оспорим или согласимся с следующими утверждениями:
1 Без ТЗ результат ХЗ.
2 Если Петя на поставленные задачи заявляет — говно и не продуманно, а Вася их решает, то Петя скоро перестанет считаться экспертом, а будет считатьсянытикомнудилой.
3 При постановке задачи, нужно не бросаться ее решать или отвергать, а с начала узнать, а зачем именно это нужно, какие проблемы энд юзера должны решится, и как именно будет применяться.
4 Бизнесу не нужны объяснения, а нужны решения.
5 Все выше перечисленное, вообще не задачи программиста.
6 Если по выходу продукта получилась невнятная хрень — это постановщики задач с дизайнерами так решили, к ним и вопросы.
Если баги и трапы замучали юзеров — это тестеры кривые, нормально оттестировать не могли.
7 Надо срочно программистам повысить зарплату.nmivan Автор
15.12.2017 07:281. Нет. Скорее «Без ТЗ результат ХЗ, с ТЗ результат говно». ХЗ дает надежду.
2. Да. Пете надо добавить чуть-чуть — делать свои решения, которые лучше предложенных. Или хотя бы предлагать.
3. Да, это само собой. В публикации предполагается, что программист толковый, и сразу это понимает, без доп.исследований. Но нас в контексте публикации интересует польза для бизнеса, а не для пользователя.
4. Нет. Бизнес — это люди. Собственникам бизнеса очень не хватает честности и правды от подчиненных. Как в мультике «Вовка в тридевятом царстве», где двое из ларца, одинаковых с лица.
5. Нет. Это программисту решать. «Я — программист» — это не приговор, и не конечная точка пути. Она вполне может быть начальной. Каждый сам решает.
6. Нет и Да. Зависит от выбранной вами зоны ответственности. Если вы работаете от задачи собственника, то такие отмазки не прокатят, а потому и проблем таких не возникнет.
7. Ни в коем случае.
Aingis
14.12.2017 20:45+1А надо всего-то уметь говорить «Нет». С какого бока какой-то левый хрен идёт к программисту? Его уже отовсюду послали? Так значит тоже надо посылать. Ответ простой: «у меня есть утверждённый круг задач, я занят ими».
Такими вопросами вообще должен заниматься как минимум Product Owner. А если бардак, и такого человека нет, то тем более не надо поощрять разрастание бардака. Вообще есть простой критерий: «мне за это дадут премию, или по башке, потому что своими задачами не занимался?»
Перечисленные варианты в статье чисто опциональные. Если хочется чэлленджа, то почему бы и нет, но надо понимать, что это дополнительная нагрузка, которую не стоит взваливать на себя, не понимая полностью ситуацию и всех последствий.
Barma2012
15.12.2017 06:59А можно пару примеров суррогата? Мне не очень понятно, что это такое, применительно к программированию.
nmivan Автор
15.12.2017 07:14В публикации речь о суррогатах применительно к бизнесу, т.е. польза ожидается для бизнеса, а ее нет. Рассматривается влияние не программирования (как физической реализации решения), а влияние выбора решения.
Если применительно к программированию, то нужно понимать, ради кого делается программирование. Цепочка получается короче — пользователю нужно одно, программист делает другое. Цели бизнеса вообще не рассматриваем — вполне вероятно, что то, что нужно пользователю, не имеет ценности для бизнеса. Если при этом оно еще и реализовано коряво, то совсем плохо. А может, и не плохо — какая разница, хорошо или плохо сделано то, что никому не нужно?
Например, программист создает и запускает внутренний корпоративный портал для компании, состоящей из 5 человек.
Или оптимизирует код корпоративной информационной системы, который используется раз в год для формирования фин.результатов, снижая время исполнения с 10 минут до 1 минуты.
Или подключает к сайту компании, работающей только по гос.заказу, систему общения с пользователями.
Вот классическая схема поэтапного «суррогатирования»:
tessob
15.12.2017 07:00Суррогаты в большинстве случаев являются следствием того, что пациент приходит к доктору ужу со своими таблетками, просто подписать рецепт. Учитывая, что в отличии от медицины, в бизнесе каждая болячка уникальна, докторам просто лень углубляться в исследование проблемы, проще подписать и забыть «как страшный сон». В любом случае возникает паритет интересов — пациенты, получают то, что просят. Пускай даже то, что они просят — это не то, что им нужно.
В крупных транснациональных компаниях (100К+ сотрудников), там между пациентом и доктором будет еще прослойка из аналитика, бизнес консультанта, деливери-менеджера и прочей нечисти. Причем, как правило, данная прослойка не владеет ни проблематикой бизнеса, ни пониманием возможных путей технической реализации. В итоге, можно наблюдать как в тратятся миллионы евро на разработку целого вороха ERP/CRM/MES систем, а когда приходишь к пользователям, то все сидят в Excel. Там процесс создания суррогатов — это уже процесс сам в себе.
mozgosteb
15.12.2017 07:14Не холивара ради. Просто хочется понять на конкретном кейсе, как его решать в рамках предложенной системы или получить объяснения, почему он к предложенной системе не имеет отношения.
Приходит человек из соответствующего отдела и говорит:
— У нас во всей системе сочетание Ctrl+A выделяет все элементы в дереве. А можешь вот в этой конкретной форме сделать чтобы Ctrl+A выделяла не все элементы, а только текущий узел и подузлы?
На вопрос «нахрена», объясняет, что все в данной форме выделять никогда не нужно. Не мотивируется аргументацией, что это против логики всей системы и windows, что пользователь никогда в жизни не нажмёт ctrl+а c мыслью что здесь оно сработает не как везде, что эта странная хотелка не бесплатна, т.к. надо городить отдельную логику.
И что, надо делать прототип? Так ведь он скажет: «да, я этого и хотел, спасибо».nmivan Автор
15.12.2017 07:19А можешь вот в этой конкретной форме сделать чтобы Ctrl+A выделяла не все элементы, а только текущий узел и подузлы?
Конкретно эта доработка выглядит полезной. Только я бы сделал не Ctrl+A, а любое другое сочетание клавиш, не используемое виндой.
Но с точки зрения бизнеса это — суррогат. Никакой пользы не будет.
На первый взгляд кажется, что сэкономится время пользователей — да, сэкономится, но они, по закону Паркинсона, просто станут работать медленнее.mozgosteb
15.12.2017 08:40Ни на что иное, кроме Ctrl+A, он не согласен, потому что «не запоминается». Что это суррогат, я понимаю. Как его не кодить без вынесения запроса на публику?
michael_vostrikov
15.12.2017 11:10Но с точки зрения бизнеса это — суррогат. Никакой пользы не будет.
да, сэкономится, но они, по закону Паркинсона, просто станут работать медленнее.Мне кажется, вы не представляете всю картину.
Если времени на работу отведено N, то наверно большинство и будет делать в течение N, но это означает не медленнее, а столько же.
Даже если времени столько же, человек потратит меньше усилий и внимания, соответственно, сможет выполнить следующую работу более эффективно, хоть и необязательно быстрее обычного M. Заметит ошибку в цифрах, подумает как улучшить что-то, или просто уйдет домой менее уставшим, а значит в целом более лояльным.
А иногда между M и N может появиться небольшая но неожиданная и срочная работа P, и такие мелочи могут сгладить перенос сроков. Например, оператор склада закончит оформлять груз до обеда, а не после.
Ctrl+A это не просто Ctrl+A, это улучшение UX. Про это вон целая наука есть. Делать его или нет, или сделать Ctrl+Q, или выводить в элементе только нужное поддерево, надо оценивать отдельно, с учетом всех факторов и мнений (выносить на публику изменения затрагивающие всех надо обязательно). Но это точно не априори "суррогат".
postgree
15.12.2017 08:40Я не согласен с одной из основных мыслей — инициатор (политик) начнёт негативные действия в любом случае. Если вы работаете в компании, где ваше мнение хоть чего то стоит, а не просто гребец в околонужном направлении, то можно научиться разговаривать с людьми. А вот проваливаться необходимо быстро и дешево. Но это автоматически получается, если следовать правилу 20/80.
TimsTims
Согласен с многими пунктами, но этот момент вызывает внутреннее противоречие:
эта грань очень тонкая, и готов поспорить, что большинство разработчиков думают примерно так, что: «ну до меня был точно суррогат, а я то сделаю как надо!». А если ты уж сразу с самого начала понимаешь, что будет получаться «суррогат», то у тебя значит хватает компетенции предложить вариант лучше, не так ли?И возвращаясь к первой проблеме — ты вроде бы пишешь не суррогаты, а в итоге вполне может выйти и суррогат.
nmivan Автор
Здесь речь не о плохом коде, а о бессмысленных с точки зрения изменениях в информационной системе. Т.к. качество работы программиста, качество исполнения не рассматривается вообще.
Это не значит, что качество не важно. Просто не является предметом рассмотрения данной публикации.