Черт знает что

Есть у нас человек, назовём его Снежинка. Этот человек, сам того не ведая, создал довольно забавную задачу, которую я предлагаю вам решить. Сразу скажу, правильного ответа я не знаю. Чтобы подогреть ваш интерес, скажу, что Снежинка не одинок в своей проблеме их там целый сугроб.

Итак, Снежинка хочет стать программистом. Теперь несколько деталей.

Кто Снежинка сейчас?

Снежинка работает кодером пишет код. Что именно написать, ему говорят в техническом задании, составленном достаточно подробно, с указанием имён таблиц, контекста исполнения, способов вызова, типов возвращаемых значений и т.д.

Код, обычно, ему дают написать несложный и не важный. Причина в особенностях Снежинки, которых две.

Ограничение гугл

Снежинка родился со смартфоном в руке. Не будем давать оценку этому факту, лишь беспристрастно опишем последствия.

Грубо говоря, Снежинка очень мало знает и умеет, т.е. у него почти пустая голова. Неплохо справляется с повседневными действиями по обслуживанию своего тела завязывать шнурки, чистить зубы, одеваться, ходить, кушать и т.д. Немного умеет взаимодействовать с социумом, во всех его проявлениях не 80lvl, но крайнего в очереди найдёт.

Почти всё остальное Снежинка тоже может сделать, хоть и не знает, и не умеет. Потому что у Снежинки есть гугл его, снежинкин, персональный резервный мозг, который хранит в себе всё, что может пригодиться в жизни. Раз есть такой прекрасный резервный мозг, основной можно не нагружать. Чем Снежинка и пользуется.

Что важно: код Снежинка тоже пишет с постоянно включенным гуглом. Конечно, он уже запомнил, как сделать цикл, присвоить значение переменной или определить функцию, но всё равно не может обходиться без своего любимца.

Итак, ограничение первое: подавляющее большинство знаний Снежинки находятся в гугле, а не в Снежинке.

Ограничение клип

Так случилось, что у Снежинки клиповое мышление. Как, почему такое произошло знает, наверное, только гугл. В качестве причин приводят и информационную интоксикацию (перебор видосов, короче), и изменения в системе школьного образования (например, дискретные тесты вместо аналоговых сочинений), кто-то приплетает даже неправильное питание.

В причинах ковыряться не будем, посмотрим на следствие: Снежинка не может сосредоточиться на одном вопросе дольше, чем на несколько минут (клип). Максимум 15, но в среднем 5-7.

К счастью для Снежинки, этого времени вполне хватает, чтобы найти решение, требуемое для работы кодером, в гугле. За время клипа Снежинка успевает даже готовые куски кода находить и копипастить.

И вот Снежинка решил подняться на уровень выше стать программистом. Или разработчиком не будем углубляться в терминологию. Более серьёзным чуваком, короче. Снежинка изъявил своё желание, и услышал требования к программисту.

Требования к программисту

Требований было несколько, приведу ключевое: там надо думать и придумывать. Названия этого процесса используются разные анализировать, проектировать, разрабатывать, тестировать, создавать и т.д. Но смысл примерно один надо думать. Снежинка спросил, что значит думать.

После долгих споров, дискуссий и мозгового штурма Снежинке дали простую формулу 23 минуты. Кратко изложу суть.

Придумать что-нибудь стоящее это создать в голове сложный интеллектуальный объект, учитывающий все особенности, ограничения, цели, возможности, взаимосвязи и т.д. Программистам часто приходится так делать, т.к. решаемая задача редко бывает абстрактной и оторванной от остального приложения, требований к быстродействию, паттернов поведения пользователей.

Для того, чтобы создать в голове сложный интеллектуальный объект, необходимо выполнить, как минимум, два условия.

Первое составные части объекта уже должны быть в голове. Не на бумаге, не в интернете, не у соседа, а в голове того, кто будет думать.

Второе думать нужно достаточно долго, 20 и более минут, чтобы объект получился качественным. Иначе получится поделка автоматизмов.

Теперь вы, наверное, уже понимаете, в чём загадка.

Загадка

Итак, подведём итоги и сформулируем загадку.

Программист должен уметь конструировать в голове сложные интеллектуальные объекты. Для этого нужно иметь в голове знания об объекте и уметь сконцентрироваться на 20 и более минут.

Снежинка хочет стать программистом. Но все знания Снежинки находятся не в его голове, а в гугле. Сконцентрироваться Снежинка способен на 5-7 минут, максимум на 15.

Как Снежинке стать программистом?

Всякая дичь случается в жизни программистов. Кидают на деньги, таскают на допросы в налоговую, угрожают арматурой, обещают испортить репутацию. Сейчас, конечно, как-то покультурнее стало, но нет-нет да и случится какая-нибудь история, достойная публикации.

Сегодняшний герой Сергей, имя вымышленное. Добро пожаловать в клуб анонимных обиженных программистов, устраивайтесь поудобнее, в комнату входит человек и говорит:

Здравствуйте, я Сергей. Мне запрещают разговаривать с клиентами. Но я в этом не виноват.

Кто такой?

Сергей называет себя программистом, потому что его так научили. На первой работе в трудовой ему сделали запись: инженер-программист. С тех пор как-то привык. Современное деление на разработчиков, тестировщиков, аналитиков и кого-бы-там-ни-было не принимает, ну да и фиг с ним.

Работал во всяких местах, лет 15-20, в основном на заводах. И программистом, и начальником программистов, и ИТ-директором. Знает автоматизацию бизнеса вдоль и поперёк, потому что долго сидел внутри и делал эту самую автоматизацию каждый день. Много работал с директорами, собственниками, подрядчиками, разными платформами и решениями. Большой специалист по эксплуатации и развитию систем. И зачем-то попёрся, на старости лет, во франч.

Франч это фирма-партнёр 1С, которая занимается продажей, внедрением, доработкой и сопровождением программных продуктов 1С. С виду примерно то же, чем занимался Сергей, только на аутсорсе. Деньги примерно те же, но работа сильно разнообразнее, т.к. работать надо со множеством продуктов ради этого и пошёл.

Первый обет молчания

У начальства были опасения, справится или нет. Как известно, заводских программистов обычно считают ленивыми толстозадыми упырями, которые только и умеют, что в носу ковыряться. А тут новые современные продукты, постоянное развитие, драйв, ещё какие-то слова, которые на собеседовании сказали. Сергей сказал, что справится, на том и порешили.

Первую неделю к Сергею все присматривались. В первую очередь, из-за возраста ему уже под 40, а вокруг одни хипстеры. Дали одну задачу сделал. Вторую тоже. Быстро, красиво, сдал с первого раза. Вроде начало получаться, все ограничения были убраны: Серёга наш чувак. Никакого поводка.

И тут повезло обратился клиент с проблемой и программным продуктом, с которыми Сергей хорошо знаком ещё с завода. Устроили скайп, послушали, обсудили. Раздался первый звоночек Сергей попросил сначала базу посмотреть, типа аудит сделать. Вообще, так не принято было, и все собравшиеся испытали смешанные чувства радость и опасение. Клиент согласился.

Но опасения подтвердились. Сергей, как приличный инженер, посмотрел не только то, что относится к задаче, но и всё остальное. Устроили второй скайп, Сергей взял слово и полчаса рассказывал клиенту, как у него всё плохо в учёте, организации взаимодействия служб, говнокод местами пованивает и мозгов нет (он это называл нет заведующего учётом человека, отвечающего за правила работы в программе и понимающего их). Да, в конце Сергей добавил, что задачу решить можно, но толку будет ноль из-за остальных проблем клиент просто не получит удовольствия.

Клиент расстроился. Менеджер расстроился. Начальник Сергея расстроился. Сергей только не расстроился думал, что здорово помог людям. Клиент ушёл думать. В тот же день позвонил менеджеру и сказал, что не будет работать с такой компанией.

Сергею устроили выволочку. Загоняли про клиентоориентированность, win-win-переговоры, мы же тут деньги зарабатываем, ограничение контекста задачи и т.д. Сергей оправдывался, рассказывал про свой опыт работы на заводах, защищался, но ошибку так и не признал. Сказал, что не будет менять стиль общения с клиентами.

Сергей предложил, в качестве альтернативы, запретить ему с клиентами разговаривать. Начальство подумало-подумало, и согласилось. В конце концов, есть кому потрындеть целый отдел менеджеров. В том, что Сергей отличный программист, они уже успели убедиться пусть этим зарабатывает на хлеб для себя и компании.

Так появился у Сергея короткий поводок. Никаких разговоров по телефону, скайпу, зуму или любым другим средствам голосовой и видеосвязи. Только электронная почта, и только через менеджера, чтобы тот мог рецензировать письма.

В принципе, Сергей был даже рад. Сел и начал просто решать задачи. В первый месяц по результатам он был на втором месте в компании. И почти все работы были сделаны по незнакомым ему программным продуктам гипотеза толковый программист в любом говне разберётся подтвердилась.

Первая индульгенция

Но тут случилось неожиданное к менеджеру обратился тот самый сбежавший клиент, и предложил возобновить переговоры. Причём, не на тему одной задачи, а решать весь список, предложенный Сергеем. По секрету признался, что походил по другим фирмам, и заметил большую разницу. Во-первых, только одна контора из всех захотела посмотреть их базу. Во-вторых, после этого они ни слова не сказали о каких-либо проблемах. А клиент часть этих проблем уже успел расковырять и убедился, что они существуют.

Пару дней была неразбериха Сергей не знал, можно ли ему разговаривать с клиентом. Запретили же. Поэтому писал большие письма, а клиент требовал видеосвязи (не любит читать и писать). В итоге разобрались, поводок отпустили, Сергей начал работать.

Взялся, сделал, всё чики-чики. Не потому, что молодец, а потому, что уже такое делал на заводе. Там это называлось навести порядок в учёте, и развлекаться таким образом приходилось после каждой смены главбуха или директора. Дела попёрли.

Появились ещё несколько клиентов, на разговор с которыми отправляли Сергея лично или через средства связи. Определённые уроки Сергей всё-таки извлёк, и втихаря стал более вежливым перестал тыкать клиента носом в его позорный учёт, просто невзначай упоминал, что есть ряд проблем, которые Сергей тоже может решить. Эта ненавязчивость была воспринята очень хорошо, и пресейлы с участием Сергея стали быстро превращаться в сейлы. Но пришла беда, откуда не ждали.

Поговорив с несколькими клиентами, Сергей всем им продал какие-то работы. И вот настал момент, когда эти работы надо делать. Как положено, все одновременно, срочно, важно и вы же обещали.

Второй обет

Сейчас лёгкое отступление. Во франче были: менеджеры, разработчики, консультанты и аналитики. Менеджер это роутер между клиентом и всеми остальными. Сам ничего не знает и не умеет по существу проблемы, занимается только организацией работ, переговорами и т.д. Разработчик умеет писать код, но плохо представляет, зачем этот код нужен, поэтому работать может только по ТЗ. Это самое ТЗ может написать аналитик он не умеет программировать, не знает программные продукты, но научился рисовать схемы, слушать заказчика, задавать уточняющие вопросы и что-то записывать в блокноте. Консультант знает программу, не умеет программировать, не умеет писать ТЗ, но может объяснить бизнес-задачу.

Сергей же умел всё вышеперечисленное, плюс понимал бизнес, знал проблемы эксплуатации системы и т.д. Не потому, что молодец, а потому, что на заводе по-другому никак. Это и стало проблемой Сергей напродавал клиентам работ, которые мог сделать только он сам.

Чисто теоретически, наверное, можно было бы декомпозировать эти работы между аналитиками, разработчиками и консультантами, если бы не парочка трудностей. Во-первых, декомпозиция работы стоила дороже, чем сама работа (словами Сергея это им сначала целый мир объяснить надо). Во-вторых, эту декомпозицию мог сделать только сам Сергей (т.е. проблема нехватки времени Сергея не решилась бы, а лишь усугубилась). В-третьих, клиенту-то как объяснить увеличение стоимости работ в 2-3 раза?

Опять велели Сергею заткнуться. С горем пополам, нарушив все сроки, работы он сделал, в полном молчании. Когда цейтнот прошёл, вернулись к теме общения Сергея с клиентами, но начальство ничего путного предложить не могло. Решение принял сам Сергей он будет ездить с менеджерами на пресейлы, но сразу будет обозначать, что работы будет делать кто-то другой. Ну и оценивать работы будет исходя из их распыления на разработчиков, аналитиков и консультантов кушать всем надо.

Пресейлы

На том и порешили. Стал Сергей гонять на встречи, трындеть по скайпу, анализировать базы клиентов, предлагать решения. Но быстро всплыла проблема а кто будет руководить этими небольшими проектами? Менеджер не может, он ни в зуб ногой. Вспомнили, что в компании есть каста т.н. руководителей проектов. Вот их и натравили на клиентов после пресейлов. Однако, стал с пугающей точностью повторяться один и тот же сценарий.

Сергей приезжает, разговаривает, анализирует, предлагает клиент в восторге. Сергей передаёт всю информацию руководителю проекта, тот организовывает работы, едет к клиенту и тот отваливается. По разным причинам, но всегда отваливается.

Сели, подумали, и решили, что виноват всё равно Сергей. Слишком велика разница между тем, что и как говорит клиенту Сергей, и что на другой день повторяют руководители проектов. Наверное, Сергей какую-то чушь несёт, отчего клиент радуется, а когда ему нормально озвучивают - почему-то отваливается.

Ну, чего делать Опять запретили Сергею с клиентами разговаривать. Теперь и на пресейлы перестали брать. Однако, не хотели просто посадить его на программирование видно же, что человек-то хороший. Решили дать ему программистов в подчинение, чтобы научил их быть, как он.

Новый виток

Сергей вспомнил, чему его учили собственники бизнесов, в которых он работал нишу искать. Голубой океан, а не в красный лезть. Подумал денёк, и понял надо заниматься сопровождением. Да и начальство к тому же выводу пришло.

Сопровождение это когда у клиента уже есть программный продукт, неважно кем внедрённый, но нет своих программистов. Одним клиентам нужна небольшая поддержка каждый месяц, другим развитие системы, третьим решение массы накопившихся проблем. В компании этот процесс был организован очень просто. За каждым клиентом закреплён менеджер, он первично принимает задачи и бегает по офису, ищет исполнителя (разработчики сидят в разных отделах, у каждого свой начальник и, соответственно, в каждой избушке свои погремушки). Исполнитель решает задачу, сдаёт клиенту, ждёт следующего бегающего менеджера.

Сергей, конечно, сделал немного иначе. Когда менеджер приносил задачу, Сергей делал инвестицию - подключался, смотрел всё остальное, находил проблемы, предлагал обсудить (или сразу решить). Три четверти клиентов не хотели выходить за рамки задачи (т.к. денег нет), поэтому Сергей просто отдавал задачу кому-то из своих программистов.

Однако, четверть клиентов, оценив компетенции и рвение Сергея, требовали встречи и обсуждения их проблем. Сергей честно сходил к начальству и спросил, можно ли ему разговаривать с клиентами. Начальство ушло думать и советоваться с менеджерами.

Менеджеры в той компании, в принципе, люди несчастные. Они не знают ни бизнеса, ни продукта, не понимают ни слова из задачи, не разбираются в квалификации специалистов (поэтому каждый раз вынуждены давать полный круг по офису, чтобы найти исполнителя). А получают процент с продаж.

И тут такая тема: большой специалист предлагает поехать к клиенту и нарыть ещё задач. Менеджеру, в принципе, можно даже никуда не ехать он просто получит потом деньги за работы Сергея и его людей. Ни один менеджер не отказался. Начальство дало добро, но с учётом известных ранее проблем не генерировать сложных задач, не отдавать потом клиента руководителю проекта, быть вежливым.

Сергей и поехал. От этих встреч он прям удовольствие испытывал, потому что попадал в абсолютно понятную, знакомую ему атмосферу: завод, стоит 1С, всё через жопу, но как-то крутится, надо навести порядок и развивать. Ровно так обстояли дела на всех заводах, куда он приходил устраиваться в штат. Ну и везде получалось.

И опять

И тут стало получаться. Клиенты радовались, сыпали задачи, Сергей раздавал их своим программистам, что-то делал сам (если сильно сложное), всё чики-чики. Но начали раздаваться тревожные звоночки клиенты отказывались общаться с менеджерами. Задачи ставили напрямую Сергею и его людям. От менеджера требовалось лишь в конце месяца документы сделать и проконтролировать оплату.

Менеджерам-то всё нравилось, а вот их начальнику нет. И тому, что над продавцами и программистами тоже. Главный продавец быстро понял, к чему идёт менеджер, в общем-то, не нужен таким клиентам. По сути, он просто принёс Сергею лид. За лид, вроде, правильно один раз заплатить, а не отстёгивать каждый месяц. Та же мысль пришла в голову главному начальнику зачем держать менеджера, платить ему деньги, если работа программистов и клиента ведётся напрямую?

Главный начальник соображал медленно, а главный продавец быстро. И решил вытащить своих сотрудников из мутных схем - по сути, практически запретил работать с Сергеем, отдавать ему клиентов целиком. Только разовые задачи, под неусыпным контролем менеджера. И, разумеется, без общения лично Сергея с клиентами.

Однако, ситуация уже вышла из-под контроля продавцов. Клиенты ведь, увы, не терпилы затюканные. Ещё вчера они общались с человеком, который понимал их с полуслова, а сегодня вынуждены снова надиктовывать задачи менеджеру, как на диктофон. Клиенты взбунтовались.

Особенно люто бесились те, что начали работать с компанией недавно, и только потому, что поговорили с Сергеем никакой менеджер, включая главного продавца, их до того окучить не мог. Посыпались угрозы расторжения договоров. Пришлось снова снимать с Сергея обет молчания.

Новая надежда

Поняв и приняв опасения менеджеров, Сергей понял: надо сделать вид, что менеджер во взаимодействии с клиентом очень-очень нужен. Попробовал поговорить об этом с самими менеджерами, но увидел лишь беззастенчивое непонимание в юных хипстерских глазах. Из полутора десятков менеджеров выбрал двух, с которыми, по его мнению, можно было хоть о чём-то договориться.

Ну и договорился. Наделил их очень важными обязанностями, типа организации встреч и переговоров, отслеживания исполнения задач, разговоров по несвязанным с задачами поводам и т.д. И не просто попросил делать всё это сказал, что сам никогда всего этого делать не будет, ни при каких обстоятельствах. А делать-то надо. Вот и острая необходимость в менеджере. Ну и начали работать.

И опять попёрло. Сергей работает с клиентом и его задачами, раздаёт их своим программистам, те быстро растут, т.к. работают в понятном контексте и под руководством человека, который понимает, что надо сделать и почему. Менеджер тоже всё время чем-то занят или вопросы по текущим клиентам решает, или новых ищет, чтобы затащить их к Сергею.

Но, как мы помним, Сергей взял только двух менеджеров, а тринадцать остались, где были. Сергей с ними тупо не работал так, по мелочи, разовые задачи брал для стажёров. Появилось неравенство среди менеджеров. Причём, не связанное с клиентами или личными заслугами менеджера. Единственным критерием успеха была работа с Сергеем и его командой.

Одних менеджеров, которые ничего не могли продать, увольняли. На их место нанимали новых, с высоким потенциалом и горящими глазами, но через несколько месяцев выгоняли. Сергей даже не пытался уже их имён запоминать смысла не было.

Начальство, наблюдая за всем этим, периодически спрашивало или требовало, чтобы с остальными менеджерами Сергей тоже работал. Тот, в принципе, был не против, и давал шанс какому-нибудь новому, или старому менеджеру.

Но счастливчик упускал свой шанс за 1-2 дня. Сыпались на мелочах не ответили на письмо, не согласовали время встречи, не озвучили стоимость работы и т.д. Не потому, что люди плохие просто работать не умели. И, увы, не хотели учиться после каждого своего косяка прибегали и пытались устроить скандал на тему программисты совсем охренели. Тут же попадали в блэклист, и вся команда Сергея получала приказ никогда с этим менеджером не работать.

Вообще дичь какая-то

Однако, долго там продолжаться не могло. Сергей понимал, что когда-нибудь ему перестанет хватать двух менеджеров его команда росла быстро. На тех, кого нанимают в продавцы, он без слёз смотреть не мог. Но продавцы нужны.

Сергей подумал и решил, что будет сам их растить. Пусть нанимаются и числятся они в другом отделе, он просто выберет одного человека, подпустит к своей команде, всё объяснит и будет новому менеджеру помогать стать профессионалом. Так и сделал.

Но опять столкнулся со старой проблемой, только на новый лад. Менеджер, принимая задачу от клиента, естественно, ни слова не понимал. Высшей степенью развития навыка продаж являлась передача информации без искажения по сути, надо было догадаться включать запись звонков. Из-за искажения информации менеджером Сергей был вынужден включаться в диалог с новыми клиентами, чтобы не дать продавцу-падавану всё испортить.

У Сергея лучше получалось поговорить с клиентом. Естественно, клиент в следующий раз хотел разговаривать только с программистом. Менеджеры уже побаивались звонков от клиентов, и всё чаще просили, а потом и требовали, чтобы Сергей участвовал в переговорах.

Тот честно попробовал. И увидел, что тратит на эти переговоры почти всё своё время. А ему надо команду развивать, да и своими руками продолжать программировать. И решил, что ему действительно пора замолчать, насовсем.

Так и сказал менеджерам: пока я разговариваю с вашими клиентами, вы этого делать так и не научитесь. То же самое повторил своим программистам (в этом не было необходимости, но Сергей, наверное, любил всё повторять).

У менеджеров была ломка несколько месяцев. Они не хотели слушать увещевания Сергея в том, что его участие медвежья услуга, которая только всё портит в перспективе. Однако, Сергей, как всегда, встал в позу и вообще, наотрез отказался разговаривать с какими-либо клиентами. Даже с любимыми, даже с директорами и собственниками.

Оставил одну лазейку электронная почта. И, вроде, пока держится. Менеджеры привыкли, и пытаются уже не чаще раза в месяц.

Понаблюдайте при случае за обустройством рабочих мест программистов. Они бывают весьма и весьма забавными. Также, присмотритесь к процессу их работы в среде разработки. Если получится, поспрашивайте, какие технические средства, облегчающие разработку, эти программисты уважают и считают наиболее важными.

А потом сходите к их начальству, соберите данные о результатах работы этих программистов, их полезности для команды/проекта/компании, в чём бы эта полезность не измерялась.

Ну и сопоставьте одно с другим особенности процесса работы с её результатами. Так вы вычислите бандерлогов.

Бандерлог это программист, работающий примерно 1-3 года. Толку от него мало, но процесс разработки у него буквально ломится от всяких полезностей и лайфхаков. Разница с совсем зелёными и 3+ обычно разительная.

У совсем зелёного всё ровно так, как было, когда его посадили за компьютер. Обои рабочего стола, цвет фона в среде разработки, расположение техники на столе, количество приколюх (равное нулю).

У программиста 3+ всё на своих местах. Нет, не так У него всё ровно там, где он поставил. И только то, что он решил. И ничего бесполезного лично для него. Каждая вещь, их взаимное расположение, настройки палитры и яркости, менюшки, перечень техники, резиновая ящерица, чётки, второй монитор, стул всё под себя. В этом ключевое отличие.

Бандерлог включает в процесс не то, что надо ему, а то же, что видит у более опытных и результативных коллег. Надо, не надо пофиг. Лишь бы как у программиста. Как говорили бандерлоги в м/ф Маугли:

Он всё умеет, всё знает!

Он такой же, как и мы, только без хвоста!

Он такой же, только голый!

Пройдёмся по основным фетишам бандерлогов.

Второй монитор

Опытные программисты используют второй монитор, чтобы не тыкать Alt+Tab. Например, на одном экране код, на втором мануал, или ТЗ, или отладка, или даже экселька.

У бандерлога на втором мониторе или ничего, или что-нибудь. Просто что-нибудь. Статичное, не участвующее в процессе. Вплоть до того, что пустой рабочий стол или второй монитор вообще выключен.

Горячие клавиши

И программисты, и бандерлоги знают горячие клавиши (хоткеи) среды разработки. Но есть принципиальная разница, в двух моментах.

Первое использование. Программисты хоткеями пользуются, а бандерлоги их просто знают.

Второе список хоткеев. Бандерлоги знают все хоткеи, потому что они их выучили. Программисты знают некоторые хоткеи, потому что они их запомнили.

Офисные принадлежности

Некоторые офисы, по старинке, выдают сотрудникам некие офисные наборы - комплекты, содержащие ручки, карандаши, ножи для бумаги, ножницы, ластики, скрепки, кнопки, степлер и т.д. Угадайте, у кого этот комплект стоит целиком?

У бандерлога, конечно. Программист берёт только то, что ему надо. Обычно это ручка, блокнот и стикеры (без клеевого края). Свой стол программист захламлять не хочет, но беззастенчиво пользуется офисным набором бандерлога, когда раз в год ему понадобится степлер.

Вспомогательное ПО

У бандерлога установлены все классные удобные программы, которые рекомендованы в подборках для разработчиков или подсмотрены у более опытных коллег. Punto Switcher, какая-нибудь штука для вырезания скриншотов, графический редактор, пять компиляторов, линейка, пипетка, запускалка программ, несколько неиспользуемых сред разработки, файловые менеджеры, ftp-менеджер и т.д.

Бандерлог всем этим не пользуется больше одного раза, но засранный ярлыками рабочий стол кажется ему более представительным и впечатляющим.

Десятипальцевый метод печати

Где-то на время жизни бандерлога в программисте приходятся попытки сознательного освоения десятипальцевого метода печати, с помощью специализированных программ.

Где-то на четвертый год эти попытки прекращаются, и начинается бессознательное овладение десятипальцевым методом. Оно как-то само случается, когда много кода и текста печатаешь.

Чего хотят бандерлоги?

Если в терминах пирамиды Маслоу, то бандерлогами движет потребность в принадлежности. Ровно та же, что движет представителями любых субкультур в юном возрасте. Второй монитор, офисный набор, бандана, косуха, розовые волосы, татуха, кольцо в носу принципиальной разницы нет.

Мы все через это проходили, в той или иной степени. И ждали одного: одобрения от других представителей субкультуры. В нашем случае от более опытных программистов.

Одобрения этого бандерлоги, как правило, не получают, т.к. программисты к этой субкультуре уже не принадлежат. Все фетиши и необходимость в них выдумана самими бандерлогами, без понимания сути и реального использования этих вещей и паттернов.

Потом всё это проходит, и бандерлог становится программистом.

Как вариант, можно не ждать три года, а пойти и объяснить бандерлогу, что он человек, и зря строит из себя обезьяну. Мой опыт говорит, что прямой разговор помогает. Тогда человек начинает концентрироваться на работе, а не на её атрибутах.

Вместо резюме

Если у вас создалось впечатление, что я негативно отношусь к прекрасному бандерложскому периоду программиста, то зря. И я, и вы были такими. И вроде ничего страшного не произошло, ничего постыдного сделано не было.

Просто время можно было провести с большей пользой.

А вы что замечали у бандерлогов?

Не только банки, дети и аниматоры умеют надувать большие пузыри. Мы, программисты, внедренцы, автоматизаторы и руководители проектов, делаем это нисколько не хуже. И, возможно, даже чаще.

Но мы круче. В определённых условиях мы умеем надувать огромные перламутровые пузыри, которые потом годами не лопаются. Толку от них нет, но Красиво же!

Проекты автоматизации

Большие проекты автоматизации бизнеса сфера, где лично я вижу пузыри чаще всего. Самые большие, красивые, дорогущие. И лопаются эти пузыри чрезвычайно красиво, оставляя на стенах и людях тонны липкой жижи.

Как ни стараются agile-цыгане, но проекты автоматизации до сих пор делаются по старинке каскад, водопад, PMBOK. Гибкие методы применяются лишь там, где не страшно ошибиться. А проект стоимостью в несколько миллионов хочется контролировать.

Пузырь растёт с самого начала проекта обследования, моделирования, написания ТЗ. Заказчик делает вид, что знает, чего ему надо. Интегратор делает вид, что не замечает, что заказчик делает вид. Все умные, толковые, деловитые и вежливые. А пузырь растёт.

Аналитики пишут ТЗ, в одном из двух вариантов. Или перечень доработок системы, купленной заказчиком, или описание целевого состояния системы, с учётом всего функционала. Заказчик читает, предлагает корректировки, кивает, подписывает. Пузырёк уже нешуточных размеров. Заказчик продолжает делать вид, что у него всё под контролем.

Тут подключаются главные надуватели программисты. Берут ТЗ и фигачат. Наше дело маленькое сделать то, что написано. Правильно написано, или чушь какая-то мы причём? Пузырь, вместе с затратами, растёт очень быстро.

Заказчик иногда делает вид, что интересуется результатом и его деталями. Смотрит на выполненные доработки, интерфейсы, формы, отчёты, цифры. Вроде что-то похожее на правду. Программисты, аналитики и РП дружно кивают да, это то, что вы просили. Стоит, переливается, немного вздрагивает на ветру. Лучше отойти и не дышать.

И наступает момент истины. Или опытная, или промышленная эксплуатация. С системой начинают работать те люди, которые пользователи. Пока пузырь надувался, они стояли в стороне это нормально, своих забот хватает. Ведь такие толковые люди систему делали, не могут они фуфло втюхать.

Тут пузырь и обнаруживается. Сделано не то и не так. Потому что спроектировано не то и не так. Потому что заказчик не то сказал Или аналитики не так поняли Или программисты не так сделали Ну, вы сами знаете, как это бывает.

Но пузырь лопается редко. Слишком он прекрасен.

Все, кто понимали, что это пузырь, давно отошли подальше программисты, аналитики, РП, а то и весь интегратор. Остаются те, кому разгребать последствия или местные программисты, или новый интегратор, или, при определённых обстоятельствах, прежняя команда.

И вот чудо: все вдруг не головой, а задницей понимают, что такое agile и зачем он нужен. Больше никаких больших ТЗ, длинных сроков разработки, ожидания в неведении. Короткие циклы, чёткие задачи, тесная работа с пользователями и реальными данными. Ну и короткие оплаты, конечно.

А пузырь стоит.

Корпоративные сайты

Ключевое отличие создания корпоративных сайтов от автоматизации пузырь надувает сам заказчик, ещё до знакомства с интегратором. Когда кто-то на совещании произносит нам точно нужен сайт - всё, можно выдавать пузырю свидетельство о рождении.

Дальше от исполнителей, т.е. создавателей сайта, уже ничего не зависит. Как бы они ни старались, в большинстве случаев построят пузырь. Собственно, пузырь им и заказали. Просто называется он корпоративный сайт.

Подрядчик, по сути, балансирует между двумя стратегиями.

Первая объяснить заказчику, что пузырь ему не нужен, и доказать это за небольшие деньги. Создать сайт с минимальной функциональностью, и оставить заказчика с ним на полгодика. Если за это время появится контент хотя бы на 10 страницах можно пробовать надувать пузырь дальше.

Вторая сделать то, что просит заказчик. Надуть большой, красивый, дорогущий пузырь. Не спрашивая и не переспрашивая, зачем такой приличной компании столько мыла и воды. Главное, как и в случае автоматизации, вовремя отойти подальше вытащить дебиторку, подписать акты, отзыв и убежать. Вдруг рванёт.

Но пузырь, скорее всего, останется. Интернет полон таких произведений искусства. До очередного умника на совещании, который скажет нам точно нужен новый сайт!.

Внутренняя автоматизация

Это сфера, созданная именно для надувания пузырей. Особенно, если внутри компании работают программисты с выдумкой и амбициями.

Ключевое отличие внутренней автоматизации она бесплатная. Программисты получают оклад, независимо от результатов. Можно ничего не делать и получать оклад. Можно надувать пузыри, прокачивая этот важный навык и получать оклад, плюс умение дуть со всей силы.

Вот и развлекаются программисты, как могут. Заниматься реально нужной автоматизацией реально скучно. Пойдёшь у пользователей или начальников спрашивать, чего вам надо для счастья каких-нибудь глупостей наговорят. Или по мелочи флажочек там добавить, кнопочку, колоночку, отчётик, или такой пузырище попросят, что никакой оклад не оправдается.

Программисты придумывают себе задачи сами. Одновременно живут два потока всякая мелочёвка для поддержания существования системы, и Большая Разработка Пузырей. Сваяет программист какую-нибудь крутую систему, по собственному разумению, отладит, насладится и Фифти-фифти.

В половине случаев попытается продать пузырь внутри компании. Найдёт подходящего заказчика, покажет ему, прорекламирует, смоделирует на реальных данных, постарается убедить, что это прям счастье. Заказчик покивает головой, лайк поставит, пообещает посмотрю потом. Процентах в 3 случаев, наверное, посмотрит.

А потом произойдёт сюжет, из которого жалобные статьи появляются. Не прижилось, Компания оказалась не готова, Я опередил завод в развитии, Меня никто не понимает и т.д. Но пузырь остаётся.

Кто продавать не умеет или не хочет просто оставляет пузырь стоять на месте. Я часто смотрю на системы, в которых местные программисты много лет надували пузыри и, поверьте на слово, получаю истинное удовольствие.

То, чем люди пользуются, сделано на скорую руку, написано на наречии говнокод, лишь бы работало. При этом рядом стоят прекрасные, огромные, амбициозные пузыри, в которые не заглядывал никто, кроме их надувателей.

Обычно в таком случае говорю начальству завода, что у них очень талантливый программист. А вот им стоит поучиться. Как минимум видеть и использовать способности людей. В идеале создавать и поддерживать среду для самореализации людей.

Да, вы правильно поняли. Я тоже пузыри надуваю иногда. Сказать директору завода в деревне создавай и поддерживай среду для самореализации людей Прям Тони Роббинс в фуфайке.

Довелось мне на стройке поработать, когда студентом был. Недолго, всего неделю. Но за это успел лицезреть целую жизнь, с необычными персонажами, перипетиями и, конечно, драмами.

Аналогичные драмы я вижу теперь каждый день на работе. Хотя, на стройке были каменщики, прорабы и разнорабочие, а на работе программисты, аналитики, разработчики, руководители проектов и начальство.

Поглядим, чему же программисты могут научиться у каменщика дяди Толи.

Исходная на стройке

На стройке работали три каменщика Костя, Рустам и дядя Толя. Косте было лет 25, Рустаму под 40, дяде Толе 50-60 (видимо, поэтому к его имени добавили уважительное дядя). Я, и еще человек 15 студентов и школьников, были разнорабочими принеси, подай, иди дальше, не мешай.

Строили мы двухэтажное здание вроде, будущее кафе. Когда я пришёл, работа велась над вторым этажом. Дядя Толя строил западную стену, Костя и Рустам северную. Южную стену пока не строили, т.к. через неё поднимали стройматериалы.

А теперь немного прервёмся и посмотрим, как дела у программистов.

Исходная на проекте

Клиент, силами каких-то чертей, внедрил себе ERP-систему. Черти, получив деньги и запустив систему, сбежали. Люди начали работать и, разумеется, огребли трудностей.

Во-первых, были плохо обучены, поэтому не всегда знали, что делать. Во-вторых, не очень хорошо были перенесены данные из прошлой системы, и нужны были корректировки. В-третьих, доработки системы под клиента плохо работали то ли спроектированы плохо были, то ли просто до ума не были доведены.

И вот вместо чертей пришла большая серьёзная компания. Т.к. работы по нормальному запуску было много, привлекли людей из двух отделов. Первый программисты, второй разработчики с аналитиками.

Программистам поручили обучение, корректировку перенесённых данных, мелкие доработки и текущую поддержку. Разработчикам исправление архитектурных ошибок чертей в больших доработках.

А теперь вернёмся на стройку и поглядим, как дела у дяди Толи и его друзей.

Процесс на стройке

Костя и Рустам посмеивались над дядей Толей, потому что он всё делал не по уму просто брал и фигачил. На любом растворе, из любого кирпича. Костя и Рустам требовали качественных материалов.

Когда цементовоз только-только приезжал раствор был свежий, и все каменщики работали. Когда раствор подсыхал, становился более вязким, Костя и Рустам останавливали работу и требовали заказать следующий цементовоз. Дядя Толя просто звал нас, разнорабочих, и говорил ребятки, пару вёдер воды плесните, и лопатами, лопатами поработайте (бетономешалки не было).

Когда привозили новый кирпич, все каменщики работали. Когда поддоны пустели, и оставалось много битого кирпича, Костя и Рустам требовали нового завоза нельзя же делать кладку из половинок, даже если она внутренняя. Дядя Толя звал нас и говорил так, пробегитесь по стройке, соберите всё от половинки и больше, и ко мне. И фигачил внутреннюю часть стены.

Костя и Рустам говорили, что дядя Толя шабашник, который просто рубит бабло. Дело в том, что каменщикам платили за кубометры выложенных стен. Костя и Рустам не могли позволить себе отступить от высоких стандартов ради быстрого результата.

Так и работали. Дядя Толя шёл примерно с той же скоростью, что Костя и Рустам вместе. Начальство не проявляло к работе дяди Толи никакого интереса. За Костей и Рустамом присматривали. Но, увы, не досмотрели.

А пока вернёмся к программистам и разработчикам.

Процесс на проекте

Программисты работали от проблемы. Сказали пользователям пишите, звоните, если чё не получается, будем вместе разбираться и решать. Когда их спросили, почему они не смотрят на систему в целом, те ответили чего на неё смотреть, она точно рабочая, мы её много раз внедряли. Это ж 1С:ERP. Там не всё гладко, но почти всё точно работает.

Им сказали проведите обучение всех пользователей. Программисты сказали нафига? Чтобы денег побольше содрать? Итак проект на волоске висит, зачем усугублять. Просто прошлись по пользователям, поспрашивали, посмотрели, и обучили по месту тех, кто был совсем ни в зуб ногой. Таких, кстати, менее четверти оказалось.

Когда возникали трудности или ошибки на каких-то участках, программистам говорили пересмотрите процесс, всю цепочку, может там перевнедрять надо. Программисты говорили не, там ошибки в мелочах. Система построена на процессном подходе, там почти всё железобетонно, принципиальную ошибку допустить сложно.

Разработчики с аналитиками взяли месяц на анализ доработок, выполненных предыдущими чертями. Чего они там анализировали им одним известно. Но счет выставили на 3 человекомесяца нетрудно догадаться, что анализировали в шесть глаз. В итоге пришли к неутешительному выводу все доработки надо переделывать, с нуля. Анализ, проектирование, разработка, тестирование, опытная эксплуатация.

Заказчик, как ни странно, согласился. Если верить слухам потому, что за месяц анализа программисты порешали большинство текущих проблем пользователей, и даже выполнили несколько доработок.

Однако, была небольшая дилемма: как работать, пока аналитики анализируют, а разработчики разрабатывают? Кривая и косая доработка под нужды заказчика, которую делали черти и собрались сносить разрабы, была прям сильно нужна. Точнее, нужна была функциональность, заложенная в этой доработке.

Выход предложили программисты. Сказали разрабам: вы там пока думайте и разрабатывайте, а мы уберём самые гнусные косяки в поделке предыдущих чертей. А когда закончите перекинем данные. На том и порешили.

Разработчики с аналитиками, естественно, посмеивались над программистами. Потому что те питаются подножным кормом, и ничем Высоким не занимаются. А программисты просто фигачили.

Но вернёмся на стройку.

Результат на стройке

Результат оказался совершенно неожиданным. Если помните, дядя Толя строил западную стену, Костя с Рустамом северную. Стены были примерно одинакового размера, и в обеих было по два окна, на одной линии, одинакового размера. Соответственно, каменщики должны были оставить под эти окна дырки.

Оставить-то они оставили. У дяди Толи всё, как задумано в проектной документации. У Кости и Рустама дырки под окна получились на разной высоте, с разницей примерно в полметра. И одно окно было смещено на метр в сторону.

Дядя Толя смеялся. Мы, разнорабочие, смеялись. Костя и Рустам махали руками и что-то громко кричали. Но прораб кричал громче, и некоторые слова даже можно процитировать. Например, зато, ***, кирпичи у вас только целые, и раствор, ***, свежий!.

А что у программистов с разработчиками?

Результат на проекте

Как вы, наверное, уже догадались, программисты быстро довели до ума то, что делали предыдущие черти. Так как работа клиента в системе началась недавно, ошибки архитектуры можно было исправить почти безболезненно не было нужды обрабатывать старые данные. Примерно в течение месяца доработанная функциональность нормально фурычила и полностью устраивала пользователей.

Но пользователи ничего не решают на проекте. Через три месяца проснулись разработчики и аналитики, выкатили своё Детище примерно ту же функциональность, только написанную с нуля. Ну и акт на 9 человекомесяцев. А счет на оплату не давали, потому что работы были предоплачены. И пришло время начальству клиента что-то решать.

Что может решить руководитель проекта со стороны заказчика, если он подписал в оплату счет на 9 человекомесяцев? Тут и к бабке не ходи. Он решил внедрять результат работы разработчиков и аналитиков. Несмотря на то, что поделка чертей уже была доведена до ума и устраивала пользователей.

Ну чего, программисты быстро написали перенос данных, перекинули одни таблицы в другие, и отошли в сторону не мешать же разработчикам с аналитиками в опытной эксплуатации.

Через две недели разработчики с аналитиками сбежали, как предыдущие черти. Кто в срочный отпуск, кто сказался больным или очень-очень занятым. Заказчик был в ступоре одно не работает, второе работает, но использовать нельзя (РПЗ запрещает).

Дело быстро дошло выше РПЗ до директора. Тот, не долго думая, повелел остановить все работы. И начались длинные разбирательства за что оплатили 9 человекомесяцев, почему разработчики с аналитиками сбежали, что они там в ТЗ написали, кто подписывал и т.д.

Пока вернёмся на стройку и поглядим, чем закончилось.

Чем закончилось на стройке

Ничего сверхъестественного просто переделали. Заложили неправильное окно, аккуратно выдолбили правильное. Пришлось, правда, повозиться.

Исправлял, естественно, дядя Толя. Костю и Рустама выгнали в тот же день.

А чем закончилось на проекте?

Чем закончилось на проекте

Директор собрал Большое Совещание. Со стороны подрядчика приехали программисты (разработчики с аналитиками, как мы помним, сбежали). Директор кричал и ругался, требовал объяснения и решения.

Когда проорался, программисты спросили так тебе объяснение или решение надо? Тот немного опешил, но сказал и то, и другое. Программисты спросили а в каком порядке? Сначала решение, потом объяснение.

Программисты и говорят есть быстро и бесплатно, есть долго и дорого. Что выбираешь? Директор выбрал быстро и бесплатно. Программисты сказали выкинуть то, что сделали разработчики с аналитиками, и пользоваться предыдущей версией доработки.

Директор опешил чё, говорит, так можно было? И пристально посмотрел на РПЗ. Тот начал что-то тараторить, но директор его грубо прервал.

Через пару дней всё заколосилось. Правда, разборки про 9 человекомесяцев идут до сих пор.

В жизни часто бывает так, что понимание явления зависит от точки наблюдения. Особенно, если эта точка находится вне традиционного контекста существования явления.

Так, что-то замудрил Я лишь хотел напомнить о том, что вы и так знаете: иногда, чтобы увидеть закон всемирного тяготения, надо получить яблоком по голове. Или, как говорится в приписываемой Эйнштейну цитате, проблему нельзя решить на том же уровне понимания, что её создал.

Области знаний постоянно проникают друг в друга, иногда обогащая и создавая неожиданный прорыв, иногда останавливая развитие лет на сто (например, при вмешательстве политики или религии в науку).

Однако, диффузия продолжается. Элементарно потому, что человек не живёт в вакууме и не занимается исключительно работой. Любой жизненный опыт, совершенно не связанный с работой, может оказать на эту самую работу влияние. Ну и наоборот, как это происходит при профессиональной деформации.

Соответственно, чем шире у человека кругозор и жизненный опыт, тем больше точек наблюдения (углов обзора, систем координат, понятийных аппаратов) он может использовать для понимания и осознания. И, вроде, это не совсем бесполезное занятие.

Я сам до этого допёр поздновато, но почитывать книги, расширяющие кругозор, всё-таки начал. На моё счастье, в очередной раз наткнулся на кота Шрёдингера. И, кажется, я понял, чего не хватало уважаемым отцам науки, для разрешения спора об условиях коллапса волновой функции, наличии и понимании состояния суперпозиции, и существовании Луны лишь в тот момент, когда вы на неё смотрите.

Им не хватало современного офиса и его сотрудников. Уж где-где, а там-то квантовая механика от души и полностью переходит от субатомных систем к макроскопическим.

Кот Шрёдингера

Сразу говорю я не специалист в квантовой механике. Я честно, несколько раз прочитал то, что нашёл про интерпретации квантовой механики, возникшие в связи с этим споры и мыслительные эксперименты, объясняющие суть этих споров. Но среди вас, дорогие читатели, конечно есть люди, которые разбираются в этом лучше меня прошу не судить строго.

Если совсем кратко, то речь о споре на тему интерпретации квантовой механики. На одной стороне стояли авторы копенгагенской интерпретации Нильс Бор и Вернер Гейзенберг. На другой Альберт Эйнштейн и Эрвин Шрёдингер. Прошу прощения, если кого забыл.

Микрочастица в квантовой механике может находиться в суперпозиции состояний, т.е. обладать одновременно взаимоисключающими свойствами например, волны и частицы. Однако, в какой-то момент происходит коллапс волновой функции, и микрочастица решает, кто она волна или частица. Спор вёлся насчет момента, или условий, при которых этот самый коллапс происходит.

Авторы копенгагенской интерпретации считали, что моментом истины выступает наблюдатель, или сам факт наблюдения, измерения, или даже взаимодействие микрочастицы с измерительным прибором. При этом, измерительный прибор относится к макромиру он большой, его можно потрогать руками. Микрочастица, вылетая из своего микромира, попадает в большой мир, сталкивается с измерительным прибором тут-то ей и приходится принять решение, волна она или частица.

С авторами копенгагенской интерпретации не были согласны Шрёдингер и Эйнштейн. Они считали, что просто ещё не всё изучено, недостаточно данных. А раз не всё понято, рано делать вывод о влиянии наблюдателя на состояние микрочастицы. Эйнштейн говорил так: Думать так логически допустимо, но это настолько противоречит моему научному инстинкту, что я не могу отказаться от поисков более полной концепции.

А Шрёдингер придумал своего знаменитого кота.

Посадим кошку в стальной сейф вместе с адской машиной (защищённой от кошки). Всчётчик Гейгераположена крупинка радиоактивного вещества,стольмалая, что за часможетраспасться один из атомов, но с такой же вероятностью может не распасться ни один. Если атом распадается, счётчик через реле приведёт в действие молоточек, который разобьёт колбу ссинильной кислотой. Предоставив эту систему самой себе в течение часа, мы скажем, что кошка ещё жива,еслиза это время не распался ни один атом. Первый же распад привёл бы к отравлению кошки.-функциявсей системы выразила бы это тем, что живая и мёртвая кошка (с позволения сказать) смешаны или размазаны в одинаковых пропорциях.

Перенеся рассуждения в макромир, Шрёдингер хотел показать неполноту знаний о микромире. Мы знаем, что кошка не может быть живой и мёртвой одновременно, т.е. находиться в суперпозиции. При этом, в эксперименте жизнь кошки напрямую зависит от микрочастицы и её состояния, которое этой самой суперпозицией и описывается. На выходе всегда определённость, на входе неопределённость.

Соответственно, хрень это всё просто надо разобраться, при каких условиях происходит коллапс волновой функции, и ни от какого наблюдателя процесс не зависит. И перестать мучить животное.

Есть же офис и его сотрудники. Которые, в отличие от кота, вполне себе могут находиться в суперпозиции. Дальше прошу читать, немного расслабившись.

Сотрудники Шрёдингера

Сотрудник офиса, любой профессии, всегда находится в суперпозиции работает и не работает одновременно. Особенно, если это сотрудник интеллектуального труда а в офисе других и не бывает.

К счастью, сотрудник Шрёдингера не сидит в коробке с колбой синильной кислоты и не является микрочастицей. Это даёт определённые преимущества: коллапс волновой функции у него случается не один раз за всю жизнь. Переход из одного состояния в другое он может совершать тысячу раз в день, без ущерба для организма.

Оттого эксперимент по определению его состояния становится ещё сложнее в этом смысле Шрёдингеру неимоверно повезло, т.к. результатом его эксперимента была переменная типа Boolean. У нас, в офисе, это функция, длиною в жизнь.

По поводу условий коллапса волновой функции сотрудника Шрёдингера, т.е. перехода в определённое состояние, всё намного интереснее, чем у кота. Там было даже скучновато: появился наблюдатель, и кот сколлапсировал - или жив, или мёртв.

Сотрудник Шрёдингера не так прост, для перехода в состояние работает необходимо, чтобы он знал, что за ним наблюдают. Даже если никакого наблюдения нет и в помине. Было бы интересно послушать мнение Шрёдингера о том, что кот мог умереть не от синильной кислоты, а от сердечного приступа, вызванного резким открыванием коробки нетерпеливым наблюдателем.

Итак, пока вы не смотрите на сотрудника Шрёдингера, он находится в суперпозиции. То ли работает, то ли нет. Вроде работает, а результата нет. Не помню, чтобы работал, но результат принёс (может, загуглил? Или это тоже работа? Или, как Сергей, прошлогодний отчёт сдал?).

Когда вы смотрите на сотрудника Шрёдингера, коллапс волновой функции, как правило, случается вы понимаете, работает сотрудник, или нет. Но это скучный, пассивный какой-то коллапс. Так, коллапсик. Грустно вздыхаете, встаёте и тяжелыми шагами направляетесь к макрочастице вашей команды.

И тут происходит чудо повторный коллапс волновой функции. Резкий вход в суперпозицию и не менее резкий выход из неё в принципиально иное состояние человек работает!

Однако, смею предположить, что и непоколебимая суперпозиция в офисе существует. Особенно, когда офис большой, сотрудников Шрёдингера много, наблюдателей мало, или наблюдатели тоже того в суперпозиции. Целый день что-то делает, но выхлопа ноль. Но делает. И зарплату получает.

Сейчас, когда работа многих людей, словами моей дочери что-то печатать на компьютере, неопределяемая, неколлапсирующая, несхлапывающаяся суперпозиция вполне может считаться вариантом нормы. Вплоть до того, что некоторые сотрудники, весь день печатая на компьютере какой-то текст, торжественно и с улыбкой его вечером удаляют. Потому что знают, что начальник Шрёдингера не знает ни про текст, ни про день, ни про сотрудника.

Да, разумеется ни одного программиста я к сотрудникам Шрёдингера не причисляю. Мы с вами всегда заняты делом и только делом. Правда, начальник это не всегда понимает, но это он сам в суперпозиции. И вообще не на своём месте. И пусть не лезет со своим наблюдением. Коллапс его волновой функции ведь от нашего труда зависит. Как и его премия. Или это одно и то же?

Что бы на это сказал Шрёдингер? Наверное, просто влепил бы минус. А Эйнштейн, наверное, плюс человек был с юмором.

Резюме

Относиться ли к этой и другим подобным темам серьёзно? Не знаю, если честно. Думаю, принимать во внимание точно стоит. Не конкретно мою попытку натянуть сову на глобус, а процесс диффузии областей знаний в принципе.

Вроде, и так все всё понимают. Есть сотрудники, за которыми не надо следить просто показать, где брать задачи, куда складывать результат. Но таких меньшинство. И чем дальше, тем меньше.

Часто начинает казаться, что для позитивного коллапса волновой функции сотрудника уже и наблюдения не хватает, и осознания наблюдаемым факта наблюдения, и угрозы резкого перехода в суперпозицию состояний у меня есть работа/у меня нет работы, и даже большие деньги не помогают. В ход идёт весь современный харэ-арсенал от геймификации до инстаграма, а эффективность всё ниже.

А потом прочитаешь что-нибудь из старого, доброго, вынырнешь из перегруженного информационного потока современных подходов к мотивации зумеров, новая версия! не пропустите! только один бесплатный вебинар, и понимаешь ага. Ничегошеньки и не изменилось, принципиально-то.

Есть сотрудник, есть начальник, есть работа. И без наблюдения никуда. Как и без измерений. И никакой разницы между новичком и опытным сотрудником нет.

Просто опытный научился наблюдать за собой самостоятельно. И выходить из суперпозиции, когда требуется. Ну и входить в неё, когда пятница.

Я верю: придёт великий день, и какой-нибудь могучий законодатель обяжет программистов 1С указывать на этикетке состав оказываемой услуги. С продуктами питания вроде получилось не всё гладко, конечно, но отличить колбасу точно не из мяса от возможно, из мяса уже получается.

Пока же у услуги доработка 1С под требования заказчика весьма и весьма мутный состав. Давайте возьмём лупу и прочитаем то, что написано мелким шрифтом.

Обучение стажёров

Ну, это прям на поверхности лежит и известно всем. Однако, упомяну.

Итак, во франчах есть стажёры и начинающие программисты. Да, им тоже надо учиться. Нет, учиться им больше негде и не на чем. Только на реальных задачах реальных клиентов. Все курсы для начинающего программиста дают лишь смутное представление о будущей профессии. Все прорешанные учебные задачи, красивые запросы, написанные в качестве диплома конфигурации почти никак не приближают человека к реальной работе.

Но не всё так просто. Бывает обучение стажёров вполне честное. Например, предварительную оценку задачи даёт профессионал, а работать будет стажёр под его присмотром, с проверкой результата и за озвученную заранее стоимость. Это приемлемо, но встречается редко.

Изредка встречается продажа стажёра, как стажёра. Например, клиенту говорят вот тебе придурошный новичок, знаний у него мало, но прыти хоть отбавляй. Бери его на 8 часов, оплатишь 1 час. Обычно под какую-нибудь работу, не требующую высокой квалификации, типа рисования бумажек, сверки остатков или вроде того.

В большинстве же случаев стажёр продаётся, как приличный программист. Распознать подделку могут только опытные клиенты по задаваемым вопросам, жестам, мимике, красному от волнения лицу (рекомендую использовать видеосвязь), дрожи в голосе и т.д.

Самая дурацкая затея покупать работу такого стажёра без предварительной оценки (сколько получится, столько получится). Получится много, при негарантированном результате. Обычно такой способ оценки работ используется, если надо разобраться, проанализировать или проверить, есть ли ошибки - в общем там, где от забора до обеда.

А вот покупать работу стажёра с предварительной оценкой, данной им самим, как ни странно, бывает выгодно. Он ведь и работать не умеет, и прогнозировать трудозатраты тоже. Как правило, называет стоимость ниже реальной, потому что не представляет, с чем имеет дело. Правда, вскоре начнёт переобуваться и просить увеличить стоимость работ, т.к. открылись новые детали (с высокой вероятностью просто открылся конфигуратор).

Комфорт Марины

Первичным приёмом задач от клиента, как правило, занимаются менеджеры по продажам. Как правило, это люди, очень плохо себе представляющие, что такое 1С. С высокой вероятностью, из всей линейки продуктов 1С менеджер видел только внутреннюю корпоративную систему франча, в котором работает.

Но от менеджера, зачастую, зависит выбор исполнителя задачи условная Марина должна примерно прикинуть, кто вообще умеет решать такое, пойти спросить и договориться, сообщить клиенту.

Но вот незадача: Марина бестолочь. Не вообще, а в том, что продаёт. Она понятия не имеет, о чём речь в задаче. Поэтому, даже не будучи программистом, Марина понимает нужен полный перебор. Надо идти по всем спецам и спрашивать. Раньше она так и делала, за что была несколько раз послана.

Любой человек, когда его посылают, испытывает дискомфорт, и Марина не исключение. Поэтому она идёт к условному Никите, с которым танцевала на корпоративе и вместе ездит в маршрутке. Никита парень хороший, и специалист неплохой, но совсем в другой области. Например, по кассам, сканерам ШК, ЕГАИС и МДЛП. А Марина принесла задачу по планированию производства. Брать? Конечно. Не смотреть же в эти мокрые от слёз глаза. Да и учиться надо не век же ползать под столом у кассиров.

Теоретически, Никита мог бы отдать задачу Васе, который собаку съел на планировании производства. Но не хочет обижать Марину это ж как подарок передарить. Поэтому Никита просто просит у Васи помощи. Тот разок поможет, другой, да и плюнет кто Марину танцует, тот пусть её и ужинает.

Если присмотреться к внутренней кухне франча, то подобных парочек, тройничков, foursome, а то и group *** обнаружится очень много. Всё бы ничего, но платит за эти оргии клиент. И неплохо бы этот ингредиент на упаковочке напечатать.

НДС

Это налог, только не на добавленную стоимость, а на дармоедов-специалистов. Одно из новшеств последних лет.

Дармоед это и не программист, и не консультант, и не аналитик, и не продавец. Просто человек, который пришёл в сферу 1С работать, потому что там вроде платят нормально. У него нет никакого подходящего образования, он никогда не программировал и не занимался учётом ни в каком виде. Но оказался достаточно живучим и сумел избежать увольнения.

Программировать не умеет вообще. Ответить без подготовки на вопрос по программе (как это делает консультант) тоже не может. Умеет тыкаться в программе и, вроде как, писать ТЗ для программистов.

Собственно, этим дармоеды и живут. Клиенту нужно разобраться в странном поведении программы или доработать её дармоед тут как тут. Он проведёт анализ, соберёт требования, оформит результаты встречи, может анкету какую заполнит, потом напишет ТЗ и включит свои услуги в стоимость. Постарается, по возможности, выделить их отдельной строкой и попросит оплатить до исполнения работы программистом. Ну так, на всякий случай.

Для франча дармоеды хорошая затычка, когда надо делать хрен-пойми-чего (а сейчас такое часто бывает). Консультанта не отправишь он вечно занят, т.к. хороший конс редкость. Программисту лень сидеть и смотреть с пользователем в экран. А дармоеду самое оно.

Так что, если вы, как клиент, общаетесь с кем-то, кроме менеджера и программиста, можно предположить, что вам накинули НДС. Процент там, увы, далеко не 20.

Вакуум

Со стороны франч выглядит, как сплочённая команда весёлых, молодых, амбициозных ребят. На самом деле это набор слабо связанных между собой групп, или даже группок. Обмена информации между ними практически нет. Процессы не выстроены, менеджмент на уровне поставить план и отойти.

Когда вы заказываете любую услугу по доработке или обслуживанию ПО 1С, будьте уверены на 99% - кто-то такое уже делал, причём в том франче, в который вы обратились. Но купите вы реализацию с нуля. И не потому, что так решили хитрозадые программисты 1С. Просто они понятия не имеют, что делают соседи и смежники.

И ладно, если вам вообще что-то продадут. Частенько бывает, что ваш запрос просто пропадёт, потому что вы попали на человека, который не знает, что и у кого надо спросить. Тыкнется получатель запроса к одному знакомому спецу, услышит а, не знаю такого, неохота вникать - и всё, цепочка прервалась.

Так что, в состав ингредиентов можно смело вносить каждый раз как в первый раз.

Маринад

Задачи, которые решают программисты 1С, частенько маринуются. Это специализированный процесс, призванный несколько увеличить стоимость итогового решения.

Например, обратился клиент за час до окончания рабочего дня. Так получилось, что нашёлся специалист, и решил задачу минут за 55 минут. Звонить, сдавать? Нафига. Оставляем до утра. И не говорим клиенту.

Если сдать сразу, то большее, на что можно рассчитывать 1 закрытый час. Если подождать до утра, то маринованная задача будет стоить уже 2, а то и 4 часа вопрос лишь в правильной подаче.

Когда задача не срочная, и может подождать несколько дней она будет мариноваться несколько дней. Если человек попался грамотный, то он в течение этого срока не будет молчать. Несколько раз позвонит или напишет, задаст уточняющие вопросы, добавит я тут делаю, вскрылось несколько дополнительных проблем, разбираюсь. Будет подливать свежего маринада.

К концу срока у клиента будет впечатление, что ему весь учёт перекопали, с головы на ноги поставили, и ещё с десяток проблем по дороге решили. Маринованная задача стоит существенно дороже.

Текучка и ротация

По давно заведённой традиции, франчи не ведут никакой документации по выполняемым у клиента работам, кроме листов учёта рабочего времени и актов оказания услуг. Исключение случаи, когда клиент прямо об этом просит. Ну и оплачивает, естественно.

Комментированием доработок тоже никто особо не парится, особенно если код рискованный, или даже позорный просто напишут //+, и всё. Даже при наличии стандарта оформления доработок, который есть почти у всех франчей причём, это документ хорошего качества. Но его читают только стажёры, в первые дни своей работы, и не понимают, что значит комментировать код, потому что не знают, что такое код. А кнопки добавить комментарий, как в соц.сетях, в коде нет.

Поэтому с клиентом постоянно работают разные специалисты. Мало того в рамках одной задачи, даже пустяковой, вполне могут смениться несколько персонажей, от дармоеда до начальника отдела, который решил тряхнуть стариной и показать неучам, как надо клиентам жизнь спасать.

А клиент ведь что частенько заказывает: доработку доработки. Он может об этом даже не подозревать, ведь текучка не только во франче есть человек видит программу, и хочет её улучшить. А кто там эту формочку рисовал, 1С или Никита ему параллельно.

Специалист же, подключаясь к задаче и видя, что надо доработать доработанное, с облегчением выдыхает ура, своё, родное! Можно смело включать в состав работ разобраться, кто это делал, как оно работает, соответствует ли текущему релизу типовой конфигурации, есть ли там ошибки. Идеальный вариант если доработать надо код другого франча. Это прям подарок.

Колобок

Чем больше франч и чем свежее клиент, тем больше он покатается по отделам, как колобок. Цель каждого отдела выжать из клиента максимум. И без разницы, что будет дальше там ведь вакуум.

Отдел продаж постарается впарить максимально дорогой продукт, лицензии с запасом на развитие, в идеале сервер и MS SQL (хотя есть бесплатный PostgreSQL), кучу сервисов и подпиской на максимальный срок, а заодно битрикс, куда ж без него. Подходит клиенту, не подходит без разницы. Внедрять-то будет другой отдел (если будет).

Внедренцы постараются раскатать приличный бюджет проекта, с предварительным обследованием, интервью, составлением графика и автоматизацией всех возможных подсистем. Ну, чтоб два раза не вставать. Цель максимально быстро внедрить хотя бы половину, актируя работы по частям, чтобы на волне предвкушения грядущего счастья клиент с радостью платил за демонстрацию будущей системы на копии тестовой базы. К моменту запуска от команды останется полтора землекопа, проданных в рабство уже на почасовую оплату.

Сопровождение дружно кинется довнедрять и перевнедрять то, что они тут понаворотили. Рисуя клиенту ужасные перспективы работы с системой, содержащей такое количество недоработок.

До лисы докатится далеко не каждый колобок.

Отсутствие опыта к эксплуатации

Неочевидно, но невероятно. Как ни странно, во франчах крайне редко встречаются специалисты, обладающие опытом эксплуатации систем.

Внедрять, разрабатывать, дорабатывать, искать и устранять ошибки всегда пожалуйста. Понимать и, главное, учитывать проблемы эксплуатации нет. Просто нет такого опыта.

Горизонт понимания спеца франча подписанный акт. Максимум полгода гарантийного срока, после которого исправление ошибок становится платным. К сожалению, непонимание эксплуатации приводит к катастрофическим ошибкам в проектировании.

Регистры пухнут, обмены рассинхронизируются, средств контроля нет, обновления по цене разработки, работать с системой может только человек, присутствовавший при её запуске и т.д. Хочется написать, что франчи просто ушлые, и сознательно закладывают в системы отложенные ошибки, чтобы потом на них зарабатывать.

Но нет, дело в банальном отсутствии опыта эксплуатации. Этот ингредиент случайная закономерность. Вроде как возможно присутствие следов арахиса, глютена и пшеницы в колбасе.

Тут я короче не знаю

Ну я и правда не знаю, как это назвать. Потому что речь пойдёт про 1С. Не про частые и радикальные изменения в некоторых современных конфигурациях, не про баги и непродуманность, а порой и недоделанность некоторых кусков. Нет, это было и будет всегда.

А вот простые в реализации, лежащие на поверхности фичи, которые сэкономили бы кучу времени клиентам и нормальным спецам, поди, пора уже и сделать. Нормальные спецы это те, которым стрёмно выставлять клиенту счёт за итоговую фразу вы напоролись на ошибку релиза, вам надо обновиться.

Кратко смысл. 1С давно и неплохо ведёт список ошибок. Там всё чётенько в какой конфигурации, в каком месте, как проявляется ошибка, при каких условиях возникает, в каком релизе появилась, в каком исправлена, способ обхода (если есть).

Клиенты в большинстве своём про этот сервис не знают. Спецы, увы, тоже. Не знаю точно, они прям не знают или не хотят знать проще ведь разобраться и найти ошибку самостоятельно, включив её в ингредиенты итогового блюда, чем потратить несколько минут и понять, что это ошибка типового релиза.

В эту яму скатываются и нормальные спецы какой смысл быть белой вороной, выставлять 15 минут за поиск информации, если можно продать 4 часа за анализ, моделирование и общение с разработчиками?

А что мешает просто связать типовые конфигурации и списки ошибок? Вот я и правда не понимаю. Вся исходная информация есть, просто лежит в двух местах, без связи друг с другом. Может, там тоже вакуум?

Можно же прям кнопку сделать в каждой форме: тыкаешь и получаешь список возможных ошибок из общего списка, с привязкой к месту, в котором тыкнул. По многим ошибкам контекст можно даже сузить, и автоматически проверить, поймал ты её, или нет например, когда ты указал неправильную комбинацию полей в документе.

Но, видимо, это или сложно, или не нужно. Поэтому ингредиент поискать ошибку типовой конфигурации за деньги клиента - вполне себе частый житель этикетки.

Лень клиента

Ну, куда без этого. На лени и безразличии к самому себе сейчас, наверное, вся продуктовая индустрия держится. Состав ингредиентов что колбасы, что программирования 1С, что создания сайта мало кому интересен. Как была всегда цена ключевым критерием выбора, так она и осталась. Ну и плюс эти эфемерные сроки исполнения, скорость реагирования и у вас известная компания.

И тут имеет значение целый ряд факторов.

Во-первых, клиент это не организация, а человек. Конкретный бухгалтер, начальник производства, главный менеджер по продажам и так далее. Ему, как и нам, в общем-то, наплевать. И на нас, и на контору, в которой он работает. В этом мы едины и непобедимы.

Во-вторых, этот самый представитель клиента ничего не платит он только заказывает. Платит собственник, который ничего не знает про нас, 1С и того самого человека. Поэтому действует своего рода принцип середины стоимость услуги не должна бросаться в глаза, выбиваться из привычного коридора, походить на экстремум. Тогда собственник не заметит.

В-третьих, вникать даже не лень не получается. Уровень профессиональной компетентности, кругозора, любознательности падает повсеместно и среди спецов франча, и среди сотрудников клиента. Может, и хочет человек вникнуть, но за разумное время не получается. Ну и бросает чего, как белая ворона, сидеть и тупить. Я не технический специалист, мне нужна комплексная услуга, я плачу за результат. Делайте и пишите в свои ингредиенты, что хотите, только из середины не выбивайтесь.

В-четвертых, у клиента такая же текучка, как во франче. Где-то меньше, где-то больше, но она есть. Подольше сидит директор, главбух бывает держится, финдир, но эти люди давно отошли от дел автоматизации. Сейчас они мониторят, наблюдают, контролируют. Что? А тот же принцип середины, чтобы экстремумов не было.

В-пятых, увы выбора-то особо нет. Ни одного не такого франча нет. Спецы да, встречаются. Они могут быть и внутри франчей, и фрилансерами, и заводскими программистами. Те, что ценят свою репутацию, не мимикрируют под среду, и иногда отказывают клиенту в работе, если видят, что он не вникает ни в детали работы, ни в результат, ни пользы, соответственно, получить не сможет.

Что там в-шестых, в-седьмых и в-остальных, думаю, сами допишете.

Какой тогда вывод делаем? Всё хорошо, и я зря тут разнылся? Клиент получает тот состав ингредиентов, которого заслуживает? Кому надо, тот и колбасу хорошую найдёт, и программиста 1С? Или сам сделает?

Чё думаете?

Я верю: придёт великий день, и какой-нибудь могучий законодатель обяжет программистов 1С указывать на этикетке состав оказываемой услуги. С продуктами питания вроде получилось не всё гладко, конечно, но отличить колбасу точно не из мяса от возможно, из мяса уже получается.

Пока же у услуги доработка 1С под требования заказчика весьма и весьма мутный состав. Давайте возьмём лупу и прочитаем то, что написано мелким шрифтом.

Обучение стажёров

Ну, это прям на поверхности лежит и известно всем. Однако, упомяну.

Итак, во франчах есть стажёры и начинающие программисты. Да, им тоже надо учиться. Нет, учиться им больше негде и не на чем. Только на реальных задачах реальных клиентов. Все курсы для начинающего программиста дают лишь смутное представление о будущей профессии. Все прорешанные учебные задачи, красивые запросы, написанные в качестве диплома конфигурации почти никак не приближают человека к реальной работе.

Но не всё так просто. Бывает обучение стажёров вполне честное. Например, предварительную оценку задачи даёт профессионал, а работать будет стажёр под его присмотром, с проверкой результата и за озвученную заранее стоимость. Это приемлемо, но встречается редко.

Изредка встречается продажа стажёра, как стажёра. Например, клиенту говорят вот тебе придурошный новичок, знаний у него мало, но прыти хоть отбавляй. Бери его на 8 часов, оплатишь 1 час. Обычно под какую-нибудь работу, не требующую высокой квалификации, типа рисования бумажек, сверки остатков или вроде того.

В большинстве же случаев стажёр продаётся, как приличный программист. Распознать подделку могут только опытные клиенты по задаваемым вопросам, жестам, мимике, красному от волнения лицу (рекомендую использовать видеосвязь), дрожи в голосе и т.д.

Самая дурацкая затея покупать работу такого стажёра без предварительной оценки (сколько получится, столько получится). Получится много, при негарантированном результате. Обычно такой способ оценки работ используется, если надо разобраться, проанализировать или проверить, есть ли ошибки - в общем там, где от забора до обеда.

А вот покупать работу стажёра с предварительной оценкой, данной им самим, как ни странно, бывает выгодно. Он ведь и работать не умеет, и прогнозировать трудозатраты тоже. Как правило, называет стоимость ниже реальной, потому что не представляет, с чем имеет дело. Правда, вскоре начнёт переобуваться и просить увеличить стоимость работ, т.к. открылись новые детали (с высокой вероятностью просто открылся конфигуратор).

Комфорт Марины

Первичным приёмом задач от клиента, как правило, занимаются менеджеры по продажам. Как правило, это люди, очень плохо себе представляющие, что такое 1С. С высокой вероятностью, из всей линейки продуктов 1С менеджер видел только внутреннюю корпоративную систему франча, в котором работает.

Но от менеджера, зачастую, зависит выбор исполнителя задачи условная Марина должна примерно прикинуть, кто вообще умеет решать такое, пойти спросить и договориться, сообщить клиенту.

Но вот незадача: Марина бестолочь. Не вообще, а в том, что продаёт. Она понятия не имеет, о чём речь в задаче. Поэтому, даже не будучи программистом, Марина понимает нужен полный перебор. Надо идти по всем спецам и спрашивать. Раньше она так и делала, за что была несколько раз послана.

Любой человек, когда его посылают, испытывает дискомфорт, и Марина не исключение. Поэтому она идёт к условному Никите, с которым танцевала на корпоративе и вместе ездит в маршрутке. Никита парень хороший, и специалист неплохой, но совсем в другой области. Например, по кассам, сканерам ШК, ЕГАИС и МДЛП. А Марина принесла задачу по планированию производства. Брать? Конечно. Не смотреть же в эти мокрые от слёз глаза. Да и учиться надо не век же ползать под столом у кассиров.

Теоретически, Никита мог бы отдать задачу Васе, который собаку съел на планировании производства. Но не хочет обижать Марину это ж как подарок передарить. Поэтому Никита просто просит у Васи помощи. Тот разок поможет, другой, да и плюнет кто Марину танцует, тот пусть её и ужинает.

Если присмотреться к внутренней кухне франча, то подобных парочек, тройничков, foursome, а то и group *** обнаружится очень много. Всё бы ничего, но платит за эти оргии клиент. И неплохо бы этот ингредиент на упаковочке напечатать.

НДС

Это налог, только не на добавленную стоимость, а на дармоедов-специалистов. Одно из новшеств последних лет.

Дармоед это и не программист, и не консультант, и не аналитик, и не продавец. Просто человек, который пришёл в сферу 1С работать, потому что там вроде платят нормально. У него нет никакого подходящего образования, он никогда не программировал и не занимался учётом ни в каком виде. Но оказался достаточно живучим и сумел избежать увольнения.

Программировать не умеет вообще. Ответить без подготовки на вопрос по программе (как это делает консультант) тоже не может. Умеет тыкаться в программе и, вроде как, писать ТЗ для программистов.

Собственно, этим дармоеды и живут. Клиенту нужно разобраться в странном поведении программы или доработать её дармоед тут как тут. Он проведёт анализ, соберёт требования, оформит результаты встречи, может анкету какую заполнит, потом напишет ТЗ и включит свои услуги в стоимость. Постарается, по возможности, выделить их отдельной строкой и попросит оплатить до исполнения работы программистом. Ну так, на всякий случай.

Для франча дармоеды хорошая затычка, когда надо делать хрен-пойми-чего (а сейчас такое часто бывает). Консультанта не отправишь он вечно занят, т.к. хороший конс редкость. Программисту лень сидеть и смотреть с пользователем в экран. А дармоеду самое оно.

Так что, если вы, как клиент, общаетесь с кем-то, кроме менеджера и программиста, можно предположить, что вам накинули НДС. Процент там, увы, далеко не 20.

Вакуум

Со стороны франч выглядит, как сплочённая команда весёлых, молодых, амбициозных ребят. На самом деле это набор слабо связанных между собой групп, или даже группок. Обмена информации между ними практически нет. Процессы не выстроены, менеджмент на уровне поставить план и отойти.

Когда вы заказываете любую услугу по доработке или обслуживанию ПО 1С, будьте уверены на 99% - кто-то такое уже делал, причём в том франче, в который вы обратились. Но купите вы реализацию с нуля. И не потому, что так решили хитрозадые программисты 1С. Просто они понятия не имеют, что делают соседи и смежники.

И ладно, если вам вообще что-то продадут. Частенько бывает, что ваш запрос просто пропадёт, потому что вы попали на человека, который не знает, что и у кого надо спросить. Тыкнется получатель запроса к одному знакомому спецу, услышит а, не знаю такого, неохота вникать - и всё, цепочка прервалась.

Так что, в состав ингредиентов можно смело вносить каждый раз как в первый раз.

Маринад

Задачи, которые решают программисты 1С, частенько маринуются. Это специализированный процесс, призванный несколько увеличить стоимость итогового решения.

Например, обратился клиент за час до окончания рабочего дня. Так получилось, что нашёлся специалист, и решил задачу минут за 55 минут. Звонить, сдавать? Нафига. Оставляем до утра. И не говорим клиенту.

Если сдать сразу, то большее, на что можно рассчитывать 1 закрытый час. Если подождать до утра, то маринованная задача будет стоить уже 2, а то и 4 часа вопрос лишь в правильной подаче.

Когда задача не срочная, и может подождать несколько дней она будет мариноваться несколько дней. Если человек попался грамотный, то он в течение этого срока не будет молчать. Несколько раз позвонит или напишет, задаст уточняющие вопросы, добавит я тут делаю, вскрылось несколько дополнительных проблем, разбираюсь. Будет подливать свежего маринада.

К концу срока у клиента будет впечатление, что ему весь учёт перекопали, с головы на ноги поставили, и ещё с десяток проблем по дороге решили. Маринованная задача стоит существенно дороже.

Текучка и ротация

По давно заведённой традиции, франчи не ведут никакой документации по выполняемым у клиента работам, кроме листов учёта рабочего времени и актов оказания услуг. Исключение случаи, когда клиент прямо об этом просит. Ну и оплачивает, естественно.

Комментированием доработок тоже никто особо не парится, особенно если код рискованный, или даже позорный просто напишут //+, и всё. Даже при наличии стандарта оформления доработок, который есть почти у всех франчей причём, это документ хорошего качества. Но его читают только стажёры, в первые дни своей работы, и не понимают, что значит комментировать код, потому что не знают, что такое код. А кнопки добавить комментарий, как в соц.сетях, в коде нет.

Поэтому с клиентом постоянно работают разные специалисты. Мало того в рамках одной задачи, даже пустяковой, вполне могут смениться несколько персонажей, от дармоеда до начальника отдела, который решил тряхнуть стариной и показать неучам, как надо клиентам жизнь спасать.

А клиент ведь что частенько заказывает: доработку доработки. Он может об этом даже не подозревать, ведь текучка не только во франче есть человек видит программу, и хочет её улучшить. А кто там эту формочку рисовал, 1С или Никита ему параллельно.

Специалист же, подключаясь к задаче и видя, что надо доработать доработанное, с облегчением выдыхает ура, своё, родное! Можно смело включать в состав работ разобраться, кто это делал, как оно работает, соответствует ли текущему релизу типовой конфигурации, есть ли там ошибки. Идеальный вариант если доработать надо код другого франча. Это прям подарок.

Колобок

Чем больше франч и чем свежее клиент, тем больше он покатается по отделам, как колобок. Цель каждого отдела выжать из клиента максимум. И без разницы, что будет дальше там ведь вакуум.

Отдел продаж постарается впарить максимально дорогой продукт, лицензии с запасом на развитие, в идеале сервер и MS SQL (хотя есть бесплатный PostgreSQL), кучу сервисов и подпиской на максимальный срок, а заодно битрикс, куда ж без него. Подходит клиенту, не подходит без разницы. Внедрять-то будет другой отдел (если будет).

Внедренцы постараются раскатать приличный бюджет проекта, с предварительным обследованием, интервью, составлением графика и автоматизацией всех возможных подсистем. Ну, чтоб два раза не вставать. Цель максимально быстро внедрить хотя бы половину, актируя работы по частям, чтобы на волне предвкушения грядущего счастья клиент с радостью платил за демонстрацию будущей системы на копии тестовой базы. К моменту запуска от команды останется полтора землекопа, проданных в рабство уже на почасовую оплату.

Сопровождение дружно кинется довнедрять и перевнедрять то, что они тут понаворотили. Рисуя клиенту ужасные перспективы работы с системой, содержащей такое количество недоработок.

До лисы докатится далеко не каждый колобок.

Отсутствие опыта к эксплуатации

Неочевидно, но невероятно. Как ни странно, во франчах крайне редко встречаются специалисты, обладающие опытом эксплуатации систем.

Внедрять, разрабатывать, дорабатывать, искать и устранять ошибки всегда пожалуйста. Понимать и, главное, учитывать проблемы эксплуатации нет. Просто нет такого опыта.

Горизонт понимания спеца франча подписанный акт. Максимум полгода гарантийного срока, после которого исправление ошибок становится платным. К сожалению, непонимание эксплуатации приводит к катастрофическим ошибкам в проектировании.

Регистры пухнут, обмены рассинхронизируются, средств контроля нет, обновления по цене разработки, работать с системой может только человек, присутствовавший при её запуске и т.д. Хочется написать, что франчи просто ушлые, и сознательно закладывают в системы отложенные ошибки, чтобы потом на них зарабатывать.

Но нет, дело в банальном отсутствии опыта эксплуатации. Этот ингредиент случайная закономерность. Вроде как возможно присутствие следов арахиса, глютена и пшеницы в колбасе.

Тут я короче не знаю

Ну я и правда не знаю, как это назвать. Потому что речь пойдёт про 1С. Не про частые и радикальные изменения в некоторых современных конфигурациях, не про баги и непродуманность, а порой и недоделанность некоторых кусков. Нет, это было и будет всегда.

А вот простые в реализации, лежащие на поверхности фичи, которые сэкономили бы кучу времени клиентам и нормальным спецам, поди, пора уже и сделать. Нормальные спецы это те, которым стрёмно выставлять клиенту счёт за итоговую фразу вы напоролись на ошибку релиза, вам надо обновиться.

Кратко смысл. 1С давно и неплохо ведёт список ошибок. Там всё чётенько в какой конфигурации, в каком месте, как проявляется ошибка, при каких условиях возникает, в каком релизе появилась, в каком исправлена, способ обхода (если есть).

Клиенты в большинстве своём про этот сервис не знают. Спецы, увы, тоже. Не знаю точно, они прям не знают или не хотят знать проще ведь разобраться и найти ошибку самостоятельно, включив её в ингредиенты итогового блюда, чем потратить несколько минут и понять, что это ошибка типового релиза.

В эту яму скатываются и нормальные спецы какой смысл быть белой вороной, выставлять 15 минут за поиск информации, если можно продать 4 часа за анализ, моделирование и общение с разработчиками?

А что мешает просто связать типовые конфигурации и списки ошибок? Вот я и правда не понимаю. Вся исходная информация есть, просто лежит в двух местах, без связи друг с другом. Может, там тоже вакуум?

Можно же прям кнопку сделать в каждой форме: тыкаешь и получаешь список возможных ошибок из общего списка, с привязкой к месту, в котором тыкнул. По многим ошибкам контекст можно даже сузить, и автоматически проверить, поймал ты её, или нет например, когда ты указал неправильную комбинацию полей в документе.

Но, видимо, это или сложно, или не нужно. Поэтому ингредиент поискать ошибку типовой конфигурации за деньги клиента - вполне себе частый житель этикетки.

Лень клиента

Ну, куда без этого. На лени и безразличии к самому себе сейчас, наверное, вся продуктовая индустрия держится. Состав ингредиентов что колбасы, что программирования 1С, что создания сайта мало кому интересен. Как была всегда цена ключевым критерием выбора, так она и осталась. Ну и плюс эти эфемерные сроки исполнения, скорость реагирования и у вас известная компания.

И тут имеет значение целый ряд факторов.

Во-первых, клиент это не организация, а человек. Конкретный бухгалтер, начальник производства, главный менеджер по продажам и так далее. Ему, как и нам, в общем-то, наплевать. И на нас, и на контору, в которой он работает. В этом мы едины и непобедимы.

Во-вторых, этот самый представитель клиента ничего не платит он только заказывает. Платит собственник, который ничего не знает про нас, 1С и того самого человека. Поэтому действует своего рода принцип середины стоимость услуги не должна бросаться в глаза, выбиваться из привычного коридора, походить на экстремум. Тогда собственник не заметит.

В-третьих, вникать даже не лень не получается. Уровень профессиональной компетентности, кругозора, любознательности падает повсеместно и среди спецов франча, и среди сотрудников клиента. Может, и хочет человек вникнуть, но за разумное время не получается. Ну и бросает чего, как белая ворона, сидеть и тупить. Я не технический специалист, мне нужна комплексная услуга, я плачу за результат. Делайте и пишите в свои ингредиенты, что хотите, только из середины не выбивайтесь.

В-четвертых, у клиента такая же текучка, как во франче. Где-то меньше, где-то больше, но она есть. Подольше сидит директор, главбух бывает держится, финдир, но эти люди давно отошли от дел автоматизации. Сейчас они мониторят, наблюдают, контролируют. Что? А тот же принцип середины, чтобы экстремумов не было.

В-пятых, увы выбора-то особо нет. Ни одного не такого франча нет. Спецы да, встречаются. Они могут быть и внутри франчей, и фрилансерами, и заводскими программистами. Те, что ценят свою репутацию, не мимикрируют под среду, и иногда отказывают клиенту в работе, если видят, что он не вникает ни в детали работы, ни в результат, ни пользы, соответственно, получить не сможет.

Что там в-шестых, в-седьмых и в-остальных, думаю, сами допишете.

Какой тогда вывод делаем? Всё хорошо, и я зря тут разнылся? Клиент получает тот состав ингредиентов, которого заслуживает? Кому надо, тот и колбасу хорошую найдёт, и программиста 1С? Или сам сделает?

Чё думаете?

Оно само!, Оно само - кто так обычно говорит?

Детишки, которые что-то сломали. С нашей, взрослой точки зрения, люди весьма безответственные.

Пользователи корпоративных информационных систем, которые стесняются рассказать, куда и зачем нажимали. С нашей, программистской точки зрения, люди бестолковые и вредные.

А от высоких руководителей вам приходилось слышать оно само? Мне приходилось.

Николай

Николай генеральный директор завода. Хороший, уважаемый человек. Однажды нашёл себе прекрасного программиста, который автоматизировал всё, что можно, включая управление тем самым заводом т.е. работу самого Николая.

Поначалу Николай ценил программиста. Потом начал читать менеджерские книги и поверил, что нет на свете никаких людей, кроме самого Николая. Есть лишь системы, процессы и функции. Любую функцию можно заменить.

Ну и заменил программиста тот, как раз, в конец обнаглел и просил денег выше рынка. Последствия не заставили себя ждать. В первую очередь, остановилось выполнение проектов автоматизации новому программисту это нафиг не было нужно. Во вторую очередь, начали рушится уже автоматизированные участки новый программист не хотел заставлять людей в них работать, те почувствовали слабину и вернулись к бумажному экселю.

Николай почуял неладное и выгнал нового программиста, нанял модернового. Потом супернового, меганового и гипернового. Автоматизация, тем временем, скатилась в каменный век.

А потом пришёл собственник и спросил, чё случилось. Николай сказал: оно само.

Виктор

Виктор был программистом и захотел стать тимлидом. Пришёл к хорошему человеку и заявил о своём желании. Хороший человек предложил мягкий вариант организовать команду внутри действующей, чтобы Виктор мог под присмотром куратора вырасти, как тимлид.

Виктору дали людей, готовые процессы и систему управления, показатели, цели, планы, и оказали всестороннюю поддержку. Особое внимание обращали на работу с людьми. Программисты люди творческие, им нельзя только приказывать и правила выдавать под роспись. Надо учитывать мотивы и цели этих людей так сказали Виктору.

Пока Виктор был в периметре старшей команды, всё было превосходно, т.к. хороший человек, Старший Брат, помогал Виктору работать с людьми. В какой-то момент совместно решили, что пора Виктору попробовать свободное плавание.

Витя тут же перестал работать с людьми. Тупо лень было это ведь сложнее, чем код писать (хотя, тут бы я поспорил). При этом, Виктор не осуществлял никаких видимых системных изменений. Процесс, показатели, система управления всё осталось на месте. Исчез только неформализуемый, неизмеряемый элемент работа с людьми.

Правда, оказалось, что измерить отсутствие работы с людьми всё-таки можно по результату. Через пару-тройку месяцев от Виктора сбежали все программисты. Несчастного вызвали на ковёр и стали разбираться, что же произошло. Витя честно показал и доказал, что никаких изменений в процесс работы не вносил.

Те, кто Витю чехвостил, на его счастье, тоже не знали, что с людьми надо работать. Поэтому оно само прокатило на ура.

Светлана

Светлана работала директором группы предприятий. По складу характера она неуёмный контролёр. Хлебом не корми, дай запросить у подчинённых отчеты, цифры, графики, мероприятия, доклады, презентации и предложения по улучшению.

Светлану много лет преследовала одна и та же проблема не получалось найти толкового начальника производства. Смотрит резюме прекрасный кандидат. Опыт, квалификация, рекомендации всё на высшем уровне. Человек прекрасно справлялся с производствами гораздо большего масштаба.

Но, как только такой красавчик попадал в подчинение к Светлане, то начинался ddos. Начальнику производства надо, собственно, производством управлять. Как минимум, в цех раз в день сходить. А ему некогда надо отвечать на письма Светланы (непременно отмеченные и словом Важно, и соответствующим красным значком).

То один отчёт надо, то другой, то фотографию рабочего дня, то планы на завтра. И все формы отчетов, как назло, хитровыдуманные не такие, как выдаёт автоматизированная система. Т.е. надо взять исходные данные из программы и долго, муторно доводить их в экселе до нужной формы.

Чуваков хватало максимум на полгода. Люди с производства продолжали ныть, что у них плохой начальник даже в цех не ходит, всё в компьютере сидит ковыряется.

Жалобы эти дошли до собственника а тот искренне любил производство и людей, работающих руками. Собрал всех, послушал, даже вызвонил уволенных начальников производства.

Пошёл к Светлане, начал выяснять. Угадайте, что она сказала.