Комментарии 56
Согласен с многими пунктами, но этот момент вызывает внутреннее противоречие:
Программист, допустим, толковый – он понимает, что предлагаемая доработка – суррогат.эта грань очень тонкая, и готов поспорить, что большинство разработчиков думают примерно так, что: «ну до меня был точно суррогат, а я то сделаю как надо!». А если ты уж сразу с самого начала понимаешь, что будет получаться «суррогат», то у тебя значит хватает компетенции предложить вариант лучше, не так ли?
Путь бизнес-программиста решает проблему производства суррогатов на корнюИ возвращаясь к первой проблеме — ты вроде бы пишешь не суррогаты, а в итоге вполне может выйти и суррогат.
Здесь речь не о плохом коде, а о бессмысленных с точки зрения изменениях в информационной системе. Т.к. качество работы программиста, качество исполнения не рассматривается вообще.
Это не значит, что качество не важно. Просто не является предметом рассмотрения данной публикации.
Это не значит, что качество не важно. Просто не является предметом рассмотрения данной публикации.
Я думаю TimsTims имел ввиду что нельзя быть уверенным в том что новая функция(фича) будет полезной. Т.е. если конкретизировать то программист видит что не хватает на сайте кнопки с отзывом, и добавляет ее, но вместо положительного эффекта это дало отрицательный. Т.е. получился суррогат.
Это как с пробками на дорогах, чтобы их решить нужно принимать не однозначное решение. (Случай с тайм сквер)
Это как с пробками на дорогах, чтобы их решить нужно принимать не однозначное решение. (Случай с тайм сквер)
Немного критики:
— Не понравился термин «Суррогат». Суррогат — это ожидаемая вещь в плохом исполнении (как например кроссовки Abibas китайского дядюшки Лао). Здесь же идёт речь о разработке ненужных или вредных систем или улучшений. Я бы назвал это «хотелками». Не особо лучше, но чётче передаёт смысл.
— Второй момент который не понравился — вы позиционируете себя борцом с системным управленческим бардаком (типичным для больших компаний и госорганизаций), но играете уже по их правилам. Отсюда и публичность и лайки и прочие подковёрные игры.
Вот что бы я делал на вашем месте:
— Будьте нацеленными на результат. Ваша задача — улучшение бизнес-процессов путём автоматизации. Рассматривайте любую идею и пытайтесь её улучшить, чтобы она соответствовала ожиданиям
— Разговаривайте, старайтесь помочь — если к вам пришли с предложением, но не спешите клеймить её «суррогатом». Сядьте вместе с просителем и проговорите как процесс работает сейчас, зачем нужна автоматизация и какой ожидаемый результат. Вежливо указывайте на недостатки предлагаемого варианта и пытайтесь найти лучшее решение или компромисс. В этом случае никто не будет обиженным и устраивать вам пакости, а компания получит нужный ей продукт
— Проактивность — это хорошо, но я бы не бежал впереди паровоза. Т.е. если есть хорошая идея — ей нужо делиться и реализовывать, но и затыкать рот другим генерируя свои идеи как из рога изобилия тоже не стоит — всё-же вы не эксперт во всех областях. Иногда лучше подойти к человеку, который работает с системой и посидеть рядом с ним и посмотреть какие процедуры неудобны. Либо собирать предложения от пользователей.
— Будьте профессионалом — не участвуйте в подковёрной борьбе, а в случае вовлечения старайтесь из неё выйти.
— В вашем подходе fail fast, fail cheap есть 2 недостатка: с одной стороны он дорогой, т.к. время тратится на разработку того, что можно было бы не делать, с другой стороны он способствует написанию плохого кода, появлению костылей и вообще ведёт к некачественному продукту. Для меня первое правило разработки — делать так, чтобы потом не переделывать, т.к. обычно переделывать времени нет.
— Не понравился термин «Суррогат». Суррогат — это ожидаемая вещь в плохом исполнении (как например кроссовки Abibas китайского дядюшки Лао). Здесь же идёт речь о разработке ненужных или вредных систем или улучшений. Я бы назвал это «хотелками». Не особо лучше, но чётче передаёт смысл.
— Второй момент который не понравился — вы позиционируете себя борцом с системным управленческим бардаком (типичным для больших компаний и госорганизаций), но играете уже по их правилам. Отсюда и публичность и лайки и прочие подковёрные игры.
Вот что бы я делал на вашем месте:
— Будьте нацеленными на результат. Ваша задача — улучшение бизнес-процессов путём автоматизации. Рассматривайте любую идею и пытайтесь её улучшить, чтобы она соответствовала ожиданиям
— Разговаривайте, старайтесь помочь — если к вам пришли с предложением, но не спешите клеймить её «суррогатом». Сядьте вместе с просителем и проговорите как процесс работает сейчас, зачем нужна автоматизация и какой ожидаемый результат. Вежливо указывайте на недостатки предлагаемого варианта и пытайтесь найти лучшее решение или компромисс. В этом случае никто не будет обиженным и устраивать вам пакости, а компания получит нужный ей продукт
— Проактивность — это хорошо, но я бы не бежал впереди паровоза. Т.е. если есть хорошая идея — ей нужо делиться и реализовывать, но и затыкать рот другим генерируя свои идеи как из рога изобилия тоже не стоит — всё-же вы не эксперт во всех областях. Иногда лучше подойти к человеку, который работает с системой и посидеть рядом с ним и посмотреть какие процедуры неудобны. Либо собирать предложения от пользователей.
— Будьте профессионалом — не участвуйте в подковёрной борьбе, а в случае вовлечения старайтесь из неё выйти.
— В вашем подходе fail fast, fail cheap есть 2 недостатка: с одной стороны он дорогой, т.к. время тратится на разработку того, что можно было бы не делать, с другой стороны он способствует написанию плохого кода, появлению костылей и вообще ведёт к некачественному продукту. Для меня первое правило разработки — делать так, чтобы потом не переделывать, т.к. обычно переделывать времени нет.
Кстати, да, "суррогат" создало в целом скорее негативный фон для статьи, хотя тема важная.
Хочется заметить по поводу
"В вашем подходе fail fast, fail cheap есть 2 недостатка: с одной стороны он дорогой, т.к. время тратится на разработку того, что можно было бы не делать, с другой стороны он способствует написанию плохого кода, появлению костылей и вообще ведёт к некачественному продукту".
На это в современных lean практиках есть решения:
- дороговизна эксперимента (а вообще если убрать свою терминологию то это и есть lean experiment) решатся за счет практик Lean UX Design и User Centric Design, т.е. любое решение начинается с проблемы пользователя и через "дешевый" прототип (банальный wireframe) валидируется на пользователях, до того как уходит в разработку
- плохой код и костыли — TDD + CI + постоянный рефакторинг
Спасибо за развернутый комментарий.
Здесь имелся в виду суррогат не ожидаемый, а подсунутый :)
Покупал как-то минералку на вокзале, оказалась вода с содой. Вот такой суррогат.
Или, из бизнеса — покупаем автоматизацию бизнеса с целью сокращения затрат, получаем повышение затрат, расширение бухгалтерии и штат программистов в придачу.
не совсем. Я, скорее, экспериментирую и пробую разные варианты — от следования их правилам, до их полного разрушения. Иногда, ради эксперимента, делаю вид, что я такой же, как они. Это как игра. В публикации отражены 4 состояния, через которые я проходил в этой игре — сопротивляться, работать за них, возглавить их, договориться с ними.
Лично мое мнение — ради жизненного опыта надо иногда поучаствовать в подковерных играх. Не настаиваю. Это увлекательно, если границы не переходить.
У меня почти так же, я предпочитаю создавать и пользоваться абстрактными настраиваемыми инструментами, чтобы делать с их помощью быстрое прототипирование. Там обычно и кода-то нет, мышкой все натыкивается, или живет в БД как временный код и запросы.
Не понравился термин «Суррогат»
Здесь имелся в виду суррогат не ожидаемый, а подсунутый :)
Покупал как-то минералку на вокзале, оказалась вода с содой. Вот такой суррогат.
Или, из бизнеса — покупаем автоматизацию бизнеса с целью сокращения затрат, получаем повышение затрат, расширение бухгалтерии и штат программистов в придачу.
вы позиционируете себя борцом с системным управленческим бардаком <...>, но играете уже по их правилам
не совсем. Я, скорее, экспериментирую и пробую разные варианты — от следования их правилам, до их полного разрушения. Иногда, ради эксперимента, делаю вид, что я такой же, как они. Это как игра. В публикации отражены 4 состояния, через которые я проходил в этой игре — сопротивляться, работать за них, возглавить их, договориться с ними.
Лично мое мнение — ради жизненного опыта надо иногда поучаствовать в подковерных играх. Не настаиваю. Это увлекательно, если границы не переходить.
Для меня первое правило разработки — делать так, чтобы потом не переделывать, т.к. обычно переделывать времени нет.
У меня почти так же, я предпочитаю создавать и пользоваться абстрактными настраиваемыми инструментами, чтобы делать с их помощью быстрое прототипирование. Там обычно и кода-то нет, мышкой все натыкивается, или живет в БД как временный код и запросы.
«Симулякр»?
Потому что воплощен в коде, выполняет в ИС какие-то действия, но при этом не оказывает положительного влияния на бизнес-процессы.
Потому что воплощен в коде, выполняет в ИС какие-то действия, но при этом не оказывает положительного влияния на бизнес-процессы.
«не участвуйте в подковёрной борьбе, а в случае вовлечения старайтесь из неё выйти»
Аккуратнее с такими советами! Именно эта тактика и стоила мне хорошей и важной карьеры на последнем рабочем месте (на высокой должности), кучи проблем со здоровьем на 2 последующих года и серьёзной трещины в семье (можно сказать пережил DDOS-атаку проблем разного рода). Только из-за того, что я «не защищая никого и не нападая ни на кого», по сути, являлся ничьим (из разных групп интересов). Такой себе «один в поле воин» для них. В связи с чем, меня поспешили и изрядно потрудились (я крепко держался) убрать.
Аккуратнее с такими советами! Именно эта тактика и стоила мне хорошей и важной карьеры на последнем рабочем месте (на высокой должности), кучи проблем со здоровьем на 2 последующих года и серьёзной трещины в семье (можно сказать пережил DDOS-атаку проблем разного рода). Только из-за того, что я «не защищая никого и не нападая ни на кого», по сути, являлся ничьим (из разных групп интересов). Такой себе «один в поле воин» для них. В связи с чем, меня поспешили и изрядно потрудились (я крепко держался) убрать.
В современной практике продуктового дизайна "fail fast" называется Lead Product Development. Он неплохо описан в книге "The Lean Startup". Несмотря на название, там не только про стартапы и не только для стартаперов.
Эээ… мне одному показалось, что суть текста: «Чтобы меньше переделывать потом, вовлекайте заинтересованных лиц в процесс разработки с самого начала, часто и регулярно.»?
Вопрос — с вашей точки зрения — система управления Саяно-Шушенской ГЭС была суррогатом — ведь в конечном итоге в нужный момент система защиты не сработала
Суррогат или нет — определяется целями потребителя.
В вашем примере цели мне, увы, не известны.
Вот есть такая система — JIRA. Сама по себе она не плохая, не хорошая. Не суррогат и не то, что нужно.
Если ее вручить дворнику для повышения его эффективности, то JIRA станет суррогатом.
Потому что «нафига козе баян».
В вашем примере цели мне, увы, не известны.
Вот есть такая система — JIRA. Сама по себе она не плохая, не хорошая. Не суррогат и не то, что нужно.
Если ее вручить дворнику для повышения его эффективности, то JIRA станет суррогатом.
Потому что «нафига козе баян».
Думается в данном случае цель известна — управление агрегатами и предотвращение аварийных ситуаций.
Автоматика на ГЭС не сработала, что привело к катастрофическим последствиям.
Сорян, не заметил, что вы про систему управления, а не про саму ГЭС.
Если авария произошла именно из-за системы управления, то — да, это суррогат.
Просили систему, которая защитит от аварии, получили систему, которая не защитила.
Если авария произошла именно из-за системы управления, то — да, это суррогат.
Просили систему, которая защитит от аварии, получили систему, которая не защитила.
Более поздний пример — неудачный запуск с космодрома Восточный — там тоже был суррогат в качестве программного блока? — то есть до некоторого момента (прошлые запуски) все работало, но изменение условий запуска привело к неудаче.
Каков критерий отличия суррогата от нормального изделия — любая система может дать неудачи и не выполнить своих функций при стечении обстоятельств.
Критерий отличия очень простой — отсутствие качественного обоснования необходимости данной фичи/продукта/..., зачастую обосновывается ссылками на какие-то мнения, попадание в мейнстрим (круто, клево, все так делают), просьбы мифических заказчиков, сулящих многомиллиардные контракты, и т.д.
Например:
— Приделайте ракете крылья.
— Зачем?
— Илон Маск, ворочаясь во сне, сказал, что будущее за ракетосамолётами.
Например:
— Приделайте ракете крылья.
— Зачем?
— Илон Маск, ворочаясь во сне, сказал, что будущее за ракетосамолётами.
В данном материале (см. выше) нет мифических заказчиков — есть некий заказчик-паразит, который просто хочет сделать изделие-суррогат — как определить паразита и как увидеть, что этот паразит хочет суррогат.
То есть разработчик лицо, заинтересованное в оплате своего труда — его мифические обещания не интересуют — точнее ему о них никто и не рассказывает — предлагается работа с соответствующим бюджетом — как определить. что проект своим контентом имеет суррогат. а заказчик представляет собой паразита
Жизнь исчерпывается статьей? Я просто привел пример типового обоснования. Если разработчика интересует только оплата труда, то зачем ему вообще запариваться на тему суррогатов? Сделал — деньги получил, возникли вопросы — показал пальцем на паразита. Лично меня как разработчика интересуют не только деньги, поэтому тема статьи мне интересна, я с этим сталкиваюсь на практике и отфильтровываю паразитов по указанному признаку невозможности качественно и количественно обосновать необходимость решения задачи.
Я просто оставлю благодарность за статью здесь.
Спасибо. Видно опытного человека.
НЛО прилетело и опубликовало эту надпись здесь
Так вот доходчиво и компактно оформлен багрепорт и сформулированы воркэрауды что даже я понял. Спасибо! Это настолько всё элементарно оказалось, а я столько нервов пожёг, эх…
Я обычно сразу спрашиваю «какую проблему решаем?» и еще несколько почему и зачем. Если на все эти вопросы получен ответ и проблема действительно решается так, как предлагает коллега, то можно двигаться дальше. Если проблема несущественна или решается легче другими средствами, то честно предлагаю решить ее проще и дешевле.
Обычно, люди способны понять, когда они из пушки по воробьям собираются стрелять, и вопрос снимается.
Если не понять в чем проблема, то «суррогаты» будут появляться регулярно. Если вы такой бизнес-программист, то надо разбираться в чем проблема, а не перехватывать инициативу по появлению суррогатов.
Обычно, люди способны понять, когда они из пушки по воробьям собираются стрелять, и вопрос снимается.
Если не понять в чем проблема, то «суррогаты» будут появляться регулярно. Если вы такой бизнес-программист, то надо разбираться в чем проблема, а не перехватывать инициативу по появлению суррогатов.
НЛО прилетело и опубликовало эту надпись здесь
Как идея с прототипами работает на практике? Проблема "суррогатов" не в том, что бизнес-заказчику будет неудобно им пользоваться — ему как раз будет удобно. Проблема в том, что любая качественная система построена на некотором дизайне, некоторых фундаментальных ограничениях. Например, "не давать прямой доступ в базу другим приложениям" или "не запускать аналитические запросы на OLTP базе".
"суррогат" именно этим и опасен — тем, что разрушает архитектуру системы, усложняя поддержку и уменьшая быстродействие. И коварен тем, что со стороны бизнес-заказчика это выглядит "программист не хочет работать".
Согласен с автором про публичность — если человек приходит к тебе с проблемой, нужно понять человека и проблему, а не создавать ему дополнительные трудности, чтобы он не создал трудности уже вам. И, в идеале, не кодить функционал, а решать проблемы.
Я считаю, что путь "бизнес-программиста" идеален. Человек, называющий себя сеньором, должен знать не только что он пишет, но и зачем и для кого. Куча плюшек за простое желание учиться.
Но как прототипирование может в этом помочь — непонятно.
Посмотрите чуть шире на прототипирование.
Бизнес-программист — это не программист для бизнеса, а программист бизнеса. Модифицирует бизнес-систему, состояющую из информационной системы, бизнес-процессов, системы мотивации, системы управления, целей.
В его ведении — вся система.
И прототипирование у него шире. Например, он может сделать прототип системы мотивации, погонять ее в тестовом режиме 3 месяца, и если при приемлемых затратах она даст прирост эффективности, то доделать и внедрить, в т.ч. автоматизировать.
Бизнес-программист — это не программист для бизнеса, а программист бизнеса. Модифицирует бизнес-систему, состояющую из информационной системы, бизнес-процессов, системы мотивации, системы управления, целей.
В его ведении — вся система.
И прототипирование у него шире. Например, он может сделать прототип системы мотивации, погонять ее в тестовом режиме 3 месяца, и если при приемлемых затратах она даст прирост эффективности, то доделать и внедрить, в т.ч. автоматизировать.
У вас какой-то замгендира получился, или как минимум начальник отдела.
Подозреваю, что вы сейчас рассуждаете с использованием штампов.
Умный, разбирается в бизнес-системах — значит гендир или его зам.
Умный, разбирается в системах мотивации — значит HR-директор.
Умный, понимает стратегию и оценивает следование ей — собственник, или как минимум гендир.
Это все значки, как у бойскаутов. Просто позиция в системе, на которой стоит человек. Позиция о человеке ничего не говорит — только то, что он смог ее занять.
Умный, разбирается в бизнес-системах — значит гендир или его зам.
Умный, разбирается в системах мотивации — значит HR-директор.
Умный, понимает стратегию и оценивает следование ей — собственник, или как минимум гендир.
Это все значки, как у бойскаутов. Просто позиция в системе, на которой стоит человек. Позиция о человеке ничего не говорит — только то, что он смог ее занять.
Отличная статья, спасибо.
Есть только один нюанс — разработанный по fail fast методике «прототип» лёгко и непринуждённо действиями менеджера может превратиться в «уже созданный продукт, готовый к внедрению». И может быть уже даже «продан».
В следствие чего программисту приходится чуть-ли не ночевать на работе подпирая костылями тот самый прототип, чтобы он хоть как-то выполнял весь разрекламированный менеджером функционал.
Есть только один нюанс — разработанный по fail fast методике «прототип» лёгко и непринуждённо действиями менеджера может превратиться в «уже созданный продукт, готовый к внедрению». И может быть уже даже «продан».
В следствие чего программисту приходится чуть-ли не ночевать на работе подпирая костылями тот самый прототип, чтобы он хоть как-то выполнял весь разрекламированный менеджером функционал.
У автора про это тоже есть, начиная со слов
Главный переключатель в fail fast – не включать публичность.
С публичностью никакого прототипа не получится. Вы будете делать все, что скажут, «от заглавной буквы У до тиража и типографии».
В моём сценарии в публичное поле ситуацию выводит менеджер заполучив в обход регламентов «прототип» от разработчика и видя прекрасный шанс продемонстрировать свою полезность. Пока разработчик занимается своими делами, веря, что прототипом доказал менеджеру «суррогатность» его идеи — этот самый менеджер уже может влетать в кабинет ГЛАВНОГО, размахивая этим «прототипом» и докладывать, что «под его чутким руководством в личное, внерабочее время была произведена супер-штука, которая принесёт компании 100500 денег. Разработана, проверена, протестирована и можно уже завтра начать поставлять клиентам».
разработанный по fail fast методике «прототип» лёгко и непринуждённо действиями менеджера может превратиться в «уже созданный продукт, готовый к внедрению»
Да, такой риск есть. Второй раз с таким можно не работать по-пацански.
Либо — иметь такой же выход наверх, как и он. Чтобы присутствовать при «продаже».
К программисту, работающему в «обычной» компании, подходит человек – пользователь системы, ...
По-хорошему, пользователю вообще не о чем разговаривать с программистом.
Но ситуация типичная:
— Бизнес-аналитик? Системный аналитик? Нет, не слышали!..
Верно. Я в жизни мало встречал бизнес-аналитиков, а те, которые попадались, подходили под определение «на, Боже, что нам негоже» — люди, не нашедшие себе места в жизни. Такие превращались в маркетологов, менеджеров СМК, или аналитиков.
Увы, это так. Беда в том, что у российского бизнеса нет понимания ценности анализа самого по себе, вне контекста автоматизации. Нет понимания, что формализованное, отделенное от носителей и очищенное от различных ad-hoc-ов описание бизнес-процессов и алгоритмов не только является хорошой страховкой от случайностей, но и позволяет провести оптимизацию бизнеса и гораздо более качественную его автоматизацию. В результате, анализом занимаются случайные люди или вообще обходятся без него и вместо продуманного применения лучших практик, получаем хаотичное внедрение «хотелок» ̶к̶о̶н̶ч̶е̶н̶ы̶х̶ конечных пользователей.
Ну и действовать. Максимально непублично.
Вы описываете сценарий, когда программист один на всю компанию, сам себе начальник, и его работой мало кто интересуется. И который к тому же не сильно загружен, раз у него есть время на посторонние проекты.
Если у вас есть начальник и ИТ-коллеги, вы не должны ничего делать без оформленной в каком-то виде просьбы. Хотя бы комментарий от бизнес-пользователя в таск-трекере. Именно потому что "Ну а дальше по стандартному сценарию: а почему мой проект не делаете, а где согласование...". Особенно если из-за ваших действий что-то не работает.
Причины изменений должны быть документированы, хотя бы для другого программиста.
Если success – довели до ума
Нет. Если success — выкинули прототип и написали заново.
Путь бизнес-программиста и Путь Спарты — они положительные, ориентированы на выполнение работ и достижение результата, пусть не того, что предполагался вначале.
Путь Главного — негативный, запрещающий какую-либо работу, очевидно не ведущую к озвученному результату. Только статус Главного предохраняет его от последствий из раздела «Ад своими руками», но это может оказаться временно — придет новый гендир и ему расскажут, что-де такой-сякой ретроград запрещает новаторство, которое могло поднять наш бизнес до небес.
Не только корпоративной. Этот «феномен» также работает в уголовных деяниях, например, на взятках — кто первый настучал, тот законопослушный гражданин.
Путь Главного — негативный, запрещающий какую-либо работу, очевидно не ведущую к озвученному результату. Только статус Главного предохраняет его от последствий из раздела «Ад своими руками», но это может оказаться временно — придет новый гендир и ему расскажут, что-де такой-сякой ретроград запрещает новаторство, которое могло поднять наш бизнес до небес.
Тут уже работает другой феномен корпоративной культуры – кто первый говорит о проблеме, тот – молодец
Не только корпоративной. Этот «феномен» также работает в уголовных деяниях, например, на взятках — кто первый настучал, тот законопослушный гражданин.
ИМХО слишком много взваливаете на программистов. Можно провести аналогию — бизнес=здание, управленец=архитектор, прораб=программист. И вот архитектор подходит к прорабу и говорит «надо нам флигель приделать». И что, прораб будет такой — блин, зачем вам флигель, он не нужен бизнесу! Нет, его задача — сделать качественно. А то что им потом никто пользоваться не будет и он парковке мешать будет — уж простите, это не задача прораба. И уж если они (архитектор и прораб) такую хрень сделали, то вот прораб, пусть и исполнитель, но уж точно не «ось зла».
+ Мне не понравилось то что автор против публичности. Вот например у меня как у технаря вообще нет шансов в непубличных подковерных играх с управленцами, no way. Так что если они намереваются сделать фигню, то я как раз таки буду требовать максимальной публичности, да, все как расписали. Но я считаю, что это правильно. Если один я стабильно принимаю лучшее решение чем 20 человек — тогда зачем они вообще нужны / почему они что-то решают?
+ fail fast это ловушка и пропаганда говнокода как оно есть. Был я на таком проекте, двух ребят попросили «быстро сделать просмотровик свг тупо посмотреть как конвертируется». Ага, спустя 2 года ещё оставались куски jquery и кривой движ. И это не оттого что они плохие программисты, нет. Это оттого, что они делали «быстро посмотреть свг», а получился полноценный редактор. Если вы начали строить водоочистительную станцию, а оказалось что её водонагревательная функция для бизнеса важнее — у вас получится хреновая водонагревательная станция. Ну или без аналогий — если fail fast продукт взлетает, то никто не будет говорить — стопе, щас берем и все переписываем заново
Вообще вся статья это просто жесточайшее продвижение принципа «эй, вася, сделай по-быстрому мне прототипчик, потом переделаем если надо». Вот правда, так и вижу светлое будущее по автору:
С: Вааась, накидай побыстрому приложение для покупки слонов
В: Семен Палыч, а где ТЗ?
С: Какое ТЗ, прост типа 2 кнопки «купить слона» и «посмотреть слона» и все, тут работы на пару минут? Вон маша нарисовала тебе, держи.
В: (не обсуждать публично надо оно или нет чтобы не ударить по политическому имиджу С) оке.
*тык тык тык*
С: Отлично, теперь добавь туда профиль пользователя. Пару дней хватит?
В: *тык тык тык*
С: Супер, теперь допили туда музыку и магазин приложений!
В: *выдает ужасного слоноподобного монстра и вешается на рабочем месте*
+ Мне не понравилось то что автор против публичности. Вот например у меня как у технаря вообще нет шансов в непубличных подковерных играх с управленцами, no way. Так что если они намереваются сделать фигню, то я как раз таки буду требовать максимальной публичности, да, все как расписали. Но я считаю, что это правильно. Если один я стабильно принимаю лучшее решение чем 20 человек — тогда зачем они вообще нужны / почему они что-то решают?
+ fail fast это ловушка и пропаганда говнокода как оно есть. Был я на таком проекте, двух ребят попросили «быстро сделать просмотровик свг тупо посмотреть как конвертируется». Ага, спустя 2 года ещё оставались куски jquery и кривой движ. И это не оттого что они плохие программисты, нет. Это оттого, что они делали «быстро посмотреть свг», а получился полноценный редактор. Если вы начали строить водоочистительную станцию, а оказалось что её водонагревательная функция для бизнеса важнее — у вас получится хреновая водонагревательная станция. Ну или без аналогий — если fail fast продукт взлетает, то никто не будет говорить — стопе, щас берем и все переписываем заново
Вообще вся статья это просто жесточайшее продвижение принципа «эй, вася, сделай по-быстрому мне прототипчик, потом переделаем если надо». Вот правда, так и вижу светлое будущее по автору:
С: Вааась, накидай побыстрому приложение для покупки слонов
В: Семен Палыч, а где ТЗ?
С: Какое ТЗ, прост типа 2 кнопки «купить слона» и «посмотреть слона» и все, тут работы на пару минут? Вон маша нарисовала тебе, держи.
В: (не обсуждать публично надо оно или нет чтобы не ударить по политическому имиджу С) оке.
*тык тык тык*
С: Отлично, теперь добавь туда профиль пользователя. Пару дней хватит?
В: *тык тык тык*
С: Супер, теперь допили туда музыку и магазин приложений!
В: *выдает ужасного слоноподобного монстра и вешается на рабочем месте*
Давайте оспорим или согласимся с следующими утверждениями:
1 Без ТЗ результат ХЗ.
2 Если Петя на поставленные задачи заявляет — говно и не продуманно, а Вася их решает, то Петя скоро перестанет считаться экспертом, а будет считатьсянытиком нудилой.
3 При постановке задачи, нужно не бросаться ее решать или отвергать, а с начала узнать, а зачем именно это нужно, какие проблемы энд юзера должны решится, и как именно будет применяться.
4 Бизнесу не нужны объяснения, а нужны решения.
5 Все выше перечисленное, вообще не задачи программиста.
6 Если по выходу продукта получилась невнятная хрень — это постановщики задач с дизайнерами так решили, к ним и вопросы.
Если баги и трапы замучали юзеров — это тестеры кривые, нормально оттестировать не могли.
7 Надо срочно программистам повысить зарплату.
1 Без ТЗ результат ХЗ.
2 Если Петя на поставленные задачи заявляет — говно и не продуманно, а Вася их решает, то Петя скоро перестанет считаться экспертом, а будет считаться
3 При постановке задачи, нужно не бросаться ее решать или отвергать, а с начала узнать, а зачем именно это нужно, какие проблемы энд юзера должны решится, и как именно будет применяться.
4 Бизнесу не нужны объяснения, а нужны решения.
5 Все выше перечисленное, вообще не задачи программиста.
6 Если по выходу продукта получилась невнятная хрень — это постановщики задач с дизайнерами так решили, к ним и вопросы.
Если баги и трапы замучали юзеров — это тестеры кривые, нормально оттестировать не могли.
7 Надо срочно программистам повысить зарплату.
1. Нет. Скорее «Без ТЗ результат ХЗ, с ТЗ результат говно». ХЗ дает надежду.
2. Да. Пете надо добавить чуть-чуть — делать свои решения, которые лучше предложенных. Или хотя бы предлагать.
3. Да, это само собой. В публикации предполагается, что программист толковый, и сразу это понимает, без доп.исследований. Но нас в контексте публикации интересует польза для бизнеса, а не для пользователя.
4. Нет. Бизнес — это люди. Собственникам бизнеса очень не хватает честности и правды от подчиненных. Как в мультике «Вовка в тридевятом царстве», где двое из ларца, одинаковых с лица.
5. Нет. Это программисту решать. «Я — программист» — это не приговор, и не конечная точка пути. Она вполне может быть начальной. Каждый сам решает.
6. Нет и Да. Зависит от выбранной вами зоны ответственности. Если вы работаете от задачи собственника, то такие отмазки не прокатят, а потому и проблем таких не возникнет.
7. Ни в коем случае.
2. Да. Пете надо добавить чуть-чуть — делать свои решения, которые лучше предложенных. Или хотя бы предлагать.
3. Да, это само собой. В публикации предполагается, что программист толковый, и сразу это понимает, без доп.исследований. Но нас в контексте публикации интересует польза для бизнеса, а не для пользователя.
4. Нет. Бизнес — это люди. Собственникам бизнеса очень не хватает честности и правды от подчиненных. Как в мультике «Вовка в тридевятом царстве», где двое из ларца, одинаковых с лица.
5. Нет. Это программисту решать. «Я — программист» — это не приговор, и не конечная точка пути. Она вполне может быть начальной. Каждый сам решает.
6. Нет и Да. Зависит от выбранной вами зоны ответственности. Если вы работаете от задачи собственника, то такие отмазки не прокатят, а потому и проблем таких не возникнет.
7. Ни в коем случае.
НЛО прилетело и опубликовало эту надпись здесь
А можно пару примеров суррогата? Мне не очень понятно, что это такое, применительно к программированию.
В публикации речь о суррогатах применительно к бизнесу, т.е. польза ожидается для бизнеса, а ее нет. Рассматривается влияние не программирования (как физической реализации решения), а влияние выбора решения.
Если применительно к программированию, то нужно понимать, ради кого делается программирование. Цепочка получается короче — пользователю нужно одно, программист делает другое. Цели бизнеса вообще не рассматриваем — вполне вероятно, что то, что нужно пользователю, не имеет ценности для бизнеса. Если при этом оно еще и реализовано коряво, то совсем плохо. А может, и не плохо — какая разница, хорошо или плохо сделано то, что никому не нужно?
Например, программист создает и запускает внутренний корпоративный портал для компании, состоящей из 5 человек.
Или оптимизирует код корпоративной информационной системы, который используется раз в год для формирования фин.результатов, снижая время исполнения с 10 минут до 1 минуты.
Или подключает к сайту компании, работающей только по гос.заказу, систему общения с пользователями.
Вот классическая схема поэтапного «суррогатирования»:
Если применительно к программированию, то нужно понимать, ради кого делается программирование. Цепочка получается короче — пользователю нужно одно, программист делает другое. Цели бизнеса вообще не рассматриваем — вполне вероятно, что то, что нужно пользователю, не имеет ценности для бизнеса. Если при этом оно еще и реализовано коряво, то совсем плохо. А может, и не плохо — какая разница, хорошо или плохо сделано то, что никому не нужно?
Например, программист создает и запускает внутренний корпоративный портал для компании, состоящей из 5 человек.
Или оптимизирует код корпоративной информационной системы, который используется раз в год для формирования фин.результатов, снижая время исполнения с 10 минут до 1 минуты.
Или подключает к сайту компании, работающей только по гос.заказу, систему общения с пользователями.
Вот классическая схема поэтапного «суррогатирования»:
Суррогаты в большинстве случаев являются следствием того, что пациент приходит к доктору ужу со своими таблетками, просто подписать рецепт. Учитывая, что в отличии от медицины, в бизнесе каждая болячка уникальна, докторам просто лень углубляться в исследование проблемы, проще подписать и забыть «как страшный сон». В любом случае возникает паритет интересов — пациенты, получают то, что просят. Пускай даже то, что они просят — это не то, что им нужно.
В крупных транснациональных компаниях (100К+ сотрудников), там между пациентом и доктором будет еще прослойка из аналитика, бизнес консультанта, деливери-менеджера и прочей нечисти. Причем, как правило, данная прослойка не владеет ни проблематикой бизнеса, ни пониманием возможных путей технической реализации. В итоге, можно наблюдать как в тратятся миллионы евро на разработку целого вороха ERP/CRM/MES систем, а когда приходишь к пользователям, то все сидят в Excel. Там процесс создания суррогатов — это уже процесс сам в себе.
В крупных транснациональных компаниях (100К+ сотрудников), там между пациентом и доктором будет еще прослойка из аналитика, бизнес консультанта, деливери-менеджера и прочей нечисти. Причем, как правило, данная прослойка не владеет ни проблематикой бизнеса, ни пониманием возможных путей технической реализации. В итоге, можно наблюдать как в тратятся миллионы евро на разработку целого вороха ERP/CRM/MES систем, а когда приходишь к пользователям, то все сидят в Excel. Там процесс создания суррогатов — это уже процесс сам в себе.
Не холивара ради. Просто хочется понять на конкретном кейсе, как его решать в рамках предложенной системы или получить объяснения, почему он к предложенной системе не имеет отношения.
Приходит человек из соответствующего отдела и говорит:
— У нас во всей системе сочетание Ctrl+A выделяет все элементы в дереве. А можешь вот в этой конкретной форме сделать чтобы Ctrl+A выделяла не все элементы, а только текущий узел и подузлы?
На вопрос «нахрена», объясняет, что все в данной форме выделять никогда не нужно. Не мотивируется аргументацией, что это против логики всей системы и windows, что пользователь никогда в жизни не нажмёт ctrl+а c мыслью что здесь оно сработает не как везде, что эта странная хотелка не бесплатна, т.к. надо городить отдельную логику.
И что, надо делать прототип? Так ведь он скажет: «да, я этого и хотел, спасибо».
Приходит человек из соответствующего отдела и говорит:
— У нас во всей системе сочетание Ctrl+A выделяет все элементы в дереве. А можешь вот в этой конкретной форме сделать чтобы Ctrl+A выделяла не все элементы, а только текущий узел и подузлы?
На вопрос «нахрена», объясняет, что все в данной форме выделять никогда не нужно. Не мотивируется аргументацией, что это против логики всей системы и windows, что пользователь никогда в жизни не нажмёт ctrl+а c мыслью что здесь оно сработает не как везде, что эта странная хотелка не бесплатна, т.к. надо городить отдельную логику.
И что, надо делать прототип? Так ведь он скажет: «да, я этого и хотел, спасибо».
А можешь вот в этой конкретной форме сделать чтобы Ctrl+A выделяла не все элементы, а только текущий узел и подузлы?
Конкретно эта доработка выглядит полезной. Только я бы сделал не Ctrl+A, а любое другое сочетание клавиш, не используемое виндой.
Но с точки зрения бизнеса это — суррогат. Никакой пользы не будет.
На первый взгляд кажется, что сэкономится время пользователей — да, сэкономится, но они, по закону Паркинсона, просто станут работать медленнее.
Ни на что иное, кроме Ctrl+A, он не согласен, потому что «не запоминается». Что это суррогат, я понимаю. Как его не кодить без вынесения запроса на публику?
Но с точки зрения бизнеса это — суррогат. Никакой пользы не будет.
да, сэкономится, но они, по закону Паркинсона, просто станут работать медленнее.
Мне кажется, вы не представляете всю картину.
Если времени на работу отведено N, то наверно большинство и будет делать в течение N, но это означает не медленнее, а столько же.
Даже если времени столько же, человек потратит меньше усилий и внимания, соответственно, сможет выполнить следующую работу более эффективно, хоть и необязательно быстрее обычного M. Заметит ошибку в цифрах, подумает как улучшить что-то, или просто уйдет домой менее уставшим, а значит в целом более лояльным.
А иногда между M и N может появиться небольшая но неожиданная и срочная работа P, и такие мелочи могут сгладить перенос сроков. Например, оператор склада закончит оформлять груз до обеда, а не после.
Ctrl+A это не просто Ctrl+A, это улучшение UX. Про это вон целая наука есть. Делать его или нет, или сделать Ctrl+Q, или выводить в элементе только нужное поддерево, надо оценивать отдельно, с учетом всех факторов и мнений (выносить на публику изменения затрагивающие всех надо обязательно). Но это точно не априори "суррогат".
Я не согласен с одной из основных мыслей — инициатор (политик) начнёт негативные действия в любом случае. Если вы работаете в компании, где ваше мнение хоть чего то стоит, а не просто гребец в околонужном направлении, то можно научиться разговаривать с людьми. А вот проваливаться необходимо быстро и дешево. Но это автоматически получается, если следовать правилу 20/80.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Это Спарта