Эта публикация — про то, как программист помогает создавать суррогаты.
Суррогат – это когда сделали не то, что нужно бизнесу. Или не так, как нужно бизнесу.
Суррогаты – это самое страшное зло, происходящее сейчас с российским бизнесом и государственным управлением. Суррогаты – это лучший в мире киллер эффективности. Что особенно приятно, мы, программисты, на этот раз не в стороне – мы на самой оси зла.
Представьте исходную ситуацию. К программисту, работающему в «обычной» компании, подходит человек – пользователь системы, он же – руководитель некоего подразделения. Просит, или предлагает, или просто нейтрально говорит – надо сделать в программе/системе/на сайте такую-то штуку.
Программист, допустим, толковый – он понимает, что предлагаемая доработка – суррогат.
Вариантов развития событий много, я приведу некоторые из них:
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. Вы применяете эту методику и интуитивно, и осознанно, каждый день. Написал, запустил отладку, проверил, двинулся дальше или переделал.
А в бизнесе так не умеют. Вы можете научить, и суррогатов станет меньше.
Суррогат – это когда сделали не то, что нужно бизнесу. Или не так, как нужно бизнесу.
Суррогаты – это самое страшное зло, происходящее сейчас с российским бизнесом и государственным управлением. Суррогаты – это лучший в мире киллер эффективности. Что особенно приятно, мы, программисты, на этот раз не в стороне – мы на самой оси зла.
С чего все начинается
Представьте исходную ситуацию. К программисту, работающему в «обычной» компании, подходит человек – пользователь системы, он же – руководитель некоего подразделения. Просит, или предлагает, или просто нейтрально говорит – надо сделать в программе/системе/на сайте такую-то штуку.
Программист, допустим, толковый – он понимает, что предлагаемая доработка – суррогат.
Вариантов развития событий много, я приведу некоторые из них:
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. Вы применяете эту методику и интуитивно, и осознанно, каждый день. Написал, запустил отладку, проверил, двинулся дальше или переделал.
А в бизнесе так не умеют. Вы можете научить, и суррогатов станет меньше.
