Комментарии 175
Люди не боты. К ним нужен подход. Хочется это бизнесу или нет. Сегодняшний ИИ, как попытка бизнеса избежать поиска подходов к людям, приведет к разрушению бизнеса и послужит хорошим уроком тем, кто относится к людям как к ботам.
Пожалуй самый релевантный комментарий к статье. Документируйте что хотите и где хотите, но если главный Вася в вашей конторе почему-то от вас внезапно ушёл, то проблема, наверное, не отсутствии документации.
Внезапно уйти можно и не по своему желанию. Bus factor не от хорошей жизни так называется. И не важно, насколько хороша компания.
Закладываться на конкретную реализацию очень маловероятных событий не имеет смысла. Bus factor может в равной мере и с собственником компании случиться, а не только с Васей.
Очень часто дело не в внезапном уходе Васи, а в неправильно организованно руководстве внутри компании, благодаря чему такие как Вася появляются.
На самом деле не работает это. В том то и прикол что у Васи информация уже в голове, изначально, потому что он этот код писал и принимал решения, он эти решения "прочувствовал" в процессе работы, а другим надо потратить время на то чтобы изучить документацию, если прост её прочитать даже внимательно, даже самую подробную это будет всё равно не тот уровень понимания системы как у Васи. И тут уже по времени, учитывая трудозатраты на актуализацию документации и время на её нормальное изучение выходит что проще сразу внимательно изучать кодовую базу.
В общем, либо ваши сотрудники бесполезны, либо их уход сильно замедляет дальнейшую работу и никак этого не избежать
В общем, либо ваши сотрудники бесполезны, либо их уход сильно замедляет дальнейшую работу и никак этого не избежать
Бесполезны, это сильно слишком сказано...
Но построение структуры компании где каждый сотрудник это винтик/фиксик, который легко заменить это нетривиальная задача.
И даже если сотрудник формально может быть заменен быстро, то новый пришедший человек на старое место, далеко не одномоментно сможет выполнять полностью свой функционал.
Это невыполнимая задача. Иначе это были бы роботы.
Кстати, если Васю во лбе не попердолило — он сам же первый будет против своей незаменимости. Хотя бы просто чтобы поболеть дома спокойно, если что. Только очень глупые и самовлюблённые незрелые умы могут кичиться своей «незаменимостью», и уж тем более — стремиться к ней.
Но… вдолдонивать коллегам хотя бы минимальное понимание своих дел, «на всякий случай» — как из болота бегемота тащить. Есть же Вася, блин. Вот когда кто-то начинает заниматься тем же участком — тут да. Тут прямо слушают, записывают, вопросы по делу задают.
Но в любом случае «всё равно не тот уровень понимания системы, как у Васи». Этого не избежать. Надо стремиться к хоть какому-то уровню понимания, чтобы база знаний в васиной части не была филькиной грамотой для всего остального отдела…
“… новый пришедший человек на старое место, далеко не одномоментно сможет выполнять полностью свой функционал.”
Могу заменить ушедшего. Но … далеко не одномонетно.
По настоящему незаменимый, это тот кто может заменить кого угодно 😁
лол, давай немного обозначим границы твоей готовности - к автобусу ты выходишь в 6.20 утра домой тебя привезут в 18.10, на это время забудь о смартфонах и интернетах, заработная плата 60-65 тыс рублей на руки. За границу ты не выездной.
Готов заменить ушедшего?
А почему нет?
Лет через 15 буду уже не актуален для нормальной работы и зарплаты, надо будет как-то дожить до пенсии, и предложенный вами вариант вполне ОК.
Именно по этому я бережно сохраняю все предложения от отечественного телекома идти сеньёр voip инженером на 100к net - Сейчас NET, а через 15 лет - вполне себе и DA
Можно попробовать свихнуться в консультанты. Да, доход нестабильный, зато нет дурака-начальника (а в таких конторах, где зарплата 65к, служебный автобус, и невыездной статус, это почти наверняка), и какая-никакая, а свобода.
В т.ч. свобода не работать с удаками.
Ну и времени полно. Книги читать, компьютер играть, внуков воспитывать (если вдруг повезло их получить).
Я б с радостью написал в вики, какие решения я принимал и почему — вот только проблема в том, что на это требуется время — а за спринтом ещё целая очередь тасков стоит.
…а вот тут явный косяк управленцев, которые не выдали помощника-ученика, который будет и слушать-ассистировать, и время для логирования высвободит, и заодно ещё и вычитает и вопросы задаст (что понятно, что непонятно, и «а почему бы и не…», которое часто приводит к такому «ой, как же я сам не допёр!»)
Ну, или жадность. Ученику тоже что-то платить надо. Но тут как с любым долгом, что техническим, что кадровым — платить потом придётся с процентами.
Я даже писал. Но оказалось бесполезным. В лучшем случае читают по диагонали, в худшем вообще не читают. Пока сами шишки не набьют, не поймут в любом случае.
Я как разработчик тоже бы с удовольствием всё описал. Но половина тасков, которые наш ПМ выдаёт выглядит так:
Выяснить детали
Прикинуть
Реализовать
Есть ещё и другая проблема, "то, что знает Вася" другим может быть неважно / неинтересно, даже если Вася хочет эти знания передать. В конце концов Вася всегда есть под рукой
А знаете почему на хабре стали массово писать такие статьи ??? А потому что условные васи которые писали сервисы и разрабатывали продукты - пакуют чемоданы и едут в нормальные страны.. их бывшие руководители давно уже уехали... На рынке РФ сейчас сборище вчерашних выпускников институтов которые буквально выпрыгнули в должности руководителей - они считают что если все задокументировать - то и любую обезьяну можно будет заставить поддерживать компанию в рабочем состоянии не вкладывая в его образование и опыт...
Самое смешное что процесс общий для всего РФ и в первую очередь касается крупных компаний. В мелких компаниях за Васю держатся )) , а дефективные дегенераты получив должность в 22 годика считают что эта должность ему досталась не потому что он был последний кому бы доверили управлять людьми и просто все уже разбежались, а потому что они прям лучшие. От своей значимости они идиоты сами расписываются в своей некомпетентности в подобных статьях.
Рекомендую этим дефективный нанимать на работу вчерашнего бомжа , ну а чё читать умеет, а в документации все же расписано...
Ну, хз. В целом да - лучших заменили второсортными. Но далеко не все за границей, между тем.
Да и разница между крупняком и мелким чаще иная - в крупняке за тебя не держаться, но локально проще и не смотря на доки и инструкции пытаются сохранять кадры, хоть и не трясутся над ними. А вот мелкие как раз и пытаются заменить Васю. Притом Васю могли схантить в крупняк, а мелкая контора могла заменить Васю Петей, который давно за границей, притом заменить за х1.5 ЗП + документация
Таки не надо приписывать злому умыслу то, то объясняется глупостью
Такое впечатление, что у вас есть что-то личное к какому-то конкретному дефективному дегенерату двадцати двух лет от роду. Тут остается только посочувствовать. Неуютно как-то, если представить вами описанное.
Мне очень нравится как вы сформировали: прочувствовал. И это ключевое. Человек существо психо-эмоциональное: логика/создание неразрывно связаны с эмоциями. Как итог, даже самая лучшая документация отражает только срез восприятия ушедшего Вами. И это не считая упущений самого Васи из-за субъективно восприятия: Да это и так понятно. Вот только понятно ему одному. Причем в тот момент времени.
Кажется документация все равно лучше чем её нет. Отчасти это правда. Но я видел проекты где старались вести (в лучших традициях статьи), вот только код и документация все равно местами кардинально разошлись.
Проблема такая же как с комментариями: рано или поздно, но кто-то изменит код, но забудет изменить комментарий. Вероятность забыть изменить документацию ещё выше.
Часто, возможно даже чаще всего, Вася намеренно держит все эти вещи при себе, никому не делегируя ни одну значимую часть своих задач. Т.к. являясь ключевым сотрудником не желает отпускать эти рычаги из своих рук. Как правило, он получает больше, чем реально заслуживает, и не в последнюю очередь именно потому, что все держит в своих руках.
Т.е. не сказать, что он ничего не делает, но за эти либо близкие деньги ему на другом месте пахать пришлось бы гораздо больше. А тут - ни стресса, ни опасности увольнения, красота. Тем более, если основное давным-давно настроил, оно работает, так, иногда смазываешь и все работает.
У нас года два назад увольнялся один такой - ему дали срок обязательной отработки 9 месяцев, подняв на эти месяцы зарплату, чтобы он все передал последователям.
ему дали срок обязательной отработки 9 месяцев, подняв на эти месяцы зарплату, чтобы он все передал последователям.
Кстати, отличный компромисс. Сам бы тоже согласился на подобное.
…стандартный, кстати, способ для тех организаций, которые имеют связи на соответствующих кафедрах и собирают самых толковых студентов. «Дважды выпускник» аккуратно передаёт дела (иной раз на это целый год уходит, причём он может уже на полставки на новом месте вживаться), все друг другом довольны и не несут репутационных потерь.
а за это время новенький уволится )))
Это бонус за длительный срок работы на одном месте. Если ты проработал десятки лет, то ты неизбежно становишься носителем таких важных знаний. Но 80% знаний о системе на одном человеке? Это явно перекос.
система методами оптимизаций и реформаций выстроилась так, что к примеру в данный момент на моем предприятии ключевыми знаниями обладают максимум по 1-2 человека на направление. Прикол в том, что передавать их некому потому как те кто хотели бы тут работать - в электронике тупы и не обладают даже базовыми понятиями, а те кто смог бы эти знания принять за эту зарплату и в такие условия работать не идут.
Человек настроил, все работает, все знает, ещё недовольны. Человек так же разберётся и в другом месте будет получать так же или больше, смена места работы как правило приводит к росту зп, а так судя по тексту не удивительно что у вас там люди делится знаниями не хотят
работало на одном предприятии несколько "дедушек" пенсионеров, пришел эфективный манегер и отправил их на пенсию, через некоторое время оказалось, что без дедушек пришла попа. А самое огорчительное, что "дедушки" возвращаться отказались. Странная ситуация, правда?
P.S. Ах да.., дедушки то вообщем то знаний и опыта не скрывали, просто молодежь их не особо стремилась перенимать. По принципу, нафига изучать как работает это старье в нашу прогрессивную эпоху искусственных интеллектов.
А может потому что руководство только на Васю и взваливало все? И это поощряло... Вася пилит 1 сервис ок - никого не дадим в помощь он вывезет, потом второй ну раз Вася сам пилит ну и делает линкует по своему на свои же библиотеки подсаживая всю компанию в зависимость. А потом вешают еще одну задачу и еще... в итоге там это и работает... начальство довольно, и деньги стрижет .... пока Вася на месте
ему дали срок обязательной отработки 9 месяцев
Эммм, что-то не припоминаю в ТК сроков отработки более чем 1 месяц (для руководителей). А уж 9 месяцев....
Был таким Васей, унесшим с собой информацию о том, как всё работает. Хочется сказать, что они это заслужили. Было бы человеческое отношение (вместо предложения передать право авторства на написанный код или катиться колбаской) - всё сложилось бы по другому.
Было бы человеческое отношение (вместо предложения передать право авторства на написанный код или катиться колбаской)
Очень странное пожелание както, а что вы имеете в виду? написали за зарплату какуюто систему и хотите сами её использовать вне работодателя?
Написал за спасибо какую-то систему и не хотел, чтобы моё имя стёрли из проекта. Право на использование передать не проблема, камнем преткновения именно строчка в списке участников стала. Зачем им это было нужно? С их слов, чтобы обезопасить проект и избежать ситуации при которой я вдруг заявлю, что не согласен с тем, как используется мой код и укажу на строчку в списке участников в качестве аргумента. Если это звучит как бессмыслица - вам не кажется.
Написал за спасибо какую-то систему
если вообще бесплатно, это одно, тут вообще можно себе всю систему забрать если вы её не передавали бюрократически
если за копейки (но всеже деньги) - то другое и тут важна была именно договоренность в плане передачи прав... формально даже если вы за 1 рубль систему продали, то исключительных прав на неё не имеете и её формальный владелец волен делать с ней всё что захочет
Если это звучит как бессмыслица - вам не кажется.
ну выглядит как бред, согласен, по этому договоренности лучше оформлять на бумаге и до начала работы
если вообще бесплатно
Да. В первом варианте договора было чётко прописано, что никакого вознаграждения не будет. Предложение его подписать возникло спустя два года работы, когда стало ясно, что вклад в разработку значителен, а юридически права всё ещё у меня. Когда они поняли, что я не особо спешу передавать права - решили подсластить пилюлю, пообещав процент от будущей прибыли указать в договоре. Но предложение показалось мне сомнительным. Было бы оно в начале разработки - другое дело, соглашусь.
В России чётко отделено право считаться автором произведения от прав на использование этого произведения.
Причём право пользоваться автоматом у работодателя если было задание на разработку, так что какая-то мутная тема...
Ничего мутного.
Работодатель заказывает и оплачивает разработку, и является собственником полученного в итоге нематериального актива. Это право собственности.
Погромист (ну и остальные причастные) которые выполняли разработку, являются её авторами. Это авторское право.
Я про конкретную ситуацию. И по факту там есть нюансы, типа а я вот после работы делал и вообще никаких бумажек что это ваш заказ, а не моя инициатива...
Если то, что вы делали после работы никак не связано с тем, что делаете на работе, ни идейно, ни технически, то оно ваше, но лучше бы вам ещё и иметь неопровержимые доказательства, что вы это делали на своём оборудовании, в свой личное время и полностью по своей инициативе. Если же есть пересечение, то не важно когда и где вы это делали. Судебная практика показывает, что написав код похожий на рабочий даже после увольнения, можно намотаться на проблемы.
Судебная практика показывает, что написав код похожий на рабочий даже после увольнения, можно намотаться на проблемы.
Так для этого надо чтоб у работодателя было все оформлено как положено, у крупняка так и будет, а у мелочи, если еще ПО непрофильное направление, то по моему в судебной практике уже работодатель будет доказывать что он не верблюд.
Обычно про авторские права на код созданный у работодателя во время работы на него подписывают бумажку ещё при устройстве к этому работодателю.
А почему Вася свалил от вас молча? Может проблема в вас?
Выгорание мб
Человеку уже настолько всё равно, что даже на полноценную передачу дел сил нет
Это две разные проблемы, и кто виноват в первой уже не имеет значения. Но вообще с текущей парадигмой трудовых отношений сам бог велел поворачиваться к работодателю тем же местом каким он к работникам спозиционировался.
так он под автобус попал
Разработчик фиксит баг с доставкой уведомлений и создаёт пул-реквест. В описании — ссылка на ADR-012 и статью про dead letter queue из базы знаний. Ревьюер открывает PR и сразу понимает: это не просто «поправил обработку ошибок», а исправление известной проблемы в очереди сообщений, у которой есть история и контекст. Без этой связки ревью превращается в допрос: «а зачем ты это изменил?», «а почему именно так?», «а ты с кем-нибудь обсуждал?». С ней — в осмысленную проверку решения.
Несколько раз перечитал, и есть стойкое ощущение, что вы колесо изобретаете. Для описанного сценария лет дцать как существует Jira и её аналоги. Любое изменение кода сопровождается тикетом с описанием, зачем мы это делаем. Текст коммита в гите начинается с номера задачи. Всегда легко понять, что когда и почему.
Если у вас так не принято в 2026 году, то у вас не с Васей проблемы.
тут про архитектурное решение, оно более общее чем конкретная задача. Тикет с номером уже следствие ADR.
И получается в итоге, как в притче про слепых и слона. Есть миллион фотографий в упор, но чтобы сложить из них слона потребуется масса усилий.
+1. Я думал, что я дурак, и чего-то не понимаю. Но оказывается такие мысли не только у меня.
Если вы разрабатываете информационную систему, то да, потому что в ней сложность имеет структурный характер, а первичные элементы сами по себе простые. Разобрались со структурой – и всё понятно. Если вы, например, управляете каким-то физическим процессом, то нет, потому что на самом деле фиг его знает, почему он именно такой.
Фокс ещё 40 лет назад предостерегал от генерализации разработки программных систем разных видов, а воз и ныне там.
Везде пытаются найти слабое звено в разработчиках.
Почему нет статьи: "уволился продажник и вся база клиентов ушла вместе с ним"?
Платите нормально Васе и не будет он никуда уходить.
Платите нормально Васе и не будет он никуда уходить.
иногда это невозможно чисто экономически, особенно если Вася перерос контору где работает
Почему нет статьи: "уволился продажник и вся база клиентов ушла вместе с ним"?
потому что это уже подсудное дело с уводом коммерческой тайны
потому что это уже подсудное дело с уводом коммерческой тайны
-- Вася, привет, скинь счет на 100500 позиций.
-- Привет, Клиент. Да я уже не работаю там, в другую фирму устроился (открыл свою)
-- Вася, ты там единственный вменямый чел был, мне без разницы от кого счет, присылай.
Подскажите, что в этом диалоге подсудного?
ЗЫ: я не продажник.
Подскажите, что в этом диалоге подсудного?ЗЫ: я не продажник.
в этом нет, но продажники уходят обычно не так, а вот так:
1) работаешь в крупной конторе по продаже ядерных реакторов, собираешь себе базу из 500 постоянных клиентов
2) открываешь своё ООО, делаешь рассылку по этим 500 клиентов что во новая контора, делаем всем скидку в 20% на новый реактор, идите к нам
одно дело если клиенты на личный номер продажника звонят по старой памяти (хотя давать продажнику на работе использовать личный номер и личную электропочту, это прям заявка на успех, 100%)
и другое когда продажник всех своих клиентов на новую свою работу перетягивает массовой рассылкой по базе
база из 500 горячих-теплых клиентов это мало того что коммерческая тайна, так еще этот актив очень много денег может стоить, его увод это буквально кража
база клиентов - это собственность работодателя
хотя давать продажнику на работе использовать личный номер и личную электропочту, это прям заявка на успех
Не подскажете, как можно не дать? Отправить в шарашку?
Корп телефон и корп почта
Наличие всего этого разве мешает ему пользоваться личными средствами связи?
Снижать процент премии если будет известно что пользуются некорп.средствами
Ну и вплоть до расставания
За такое можно и в суде встретиться.
Кроме того, я, как клиент, менее вероятно стал бы вести важные дела с компанией, с сотрудниками которой не имею личных связей и, условно говоря, мы не пьём вместе водку семьями. В этом я сторонник китайского подхода. Малознакомого человека сам бог велел надурить.
я, как клиент, менее вероятно стал бы вести важные дела с компанией, с сотрудниками которой не имею личных связей и, условно говоря, мы не пьём вместе водку семьями
у вас очень своеобразный подход
Вы в магазине хлеб когда покупаете, пьете водку с семьей директора магазина?
А причём здесь директор? Директор о качестве хлеба в магазине своей торговой сети не знает вообще ничего, и никак особенно на него не влияет. Другое дело – продавец, который видел, как этот хлеб валялся на грязном полу и его грызли мышки.
Отвечая, однако, на ваш вопрос – нет, хлеб я покупаю анонимно (хотя знаю людей, которые и в этом случае заводят личные контакты). Но мы говорим о продажнике с базой из 500 важных клиентов, и он, видимо, не хлебом в магазине торгует.
ну это я утрировал конечно
вот у меня был бизнес, и я закупал всякое рекламное оборудование у пары разных фирм и были еще фирмы с которыми мы совместно размещали друг у друга рекламу (у меня рекламное агентство было)
в вашей парадигме мне надо было близкие отношения с продажниками партнеров вести чтобы быть в чемто уверенным?
Если вы собственник бизнеса, то вам в моей парадигме надо иметь близкие отношения с собственниками. В гольф там играть вместе, на остров ездить к девочкам*, или что там требуется по социальному протоколу в конкретной локации. В России вот в баню часто вместе ходят, полезное дело во всех отношениях.
Если вы закупщик – то с продажниками. И т.д.
Вам же, как собственнику, не важна конкретная закупка, вам деньги нужно отбить? Зачем вам тогда близкие отношения с продажниками.
---
*Не является пропагандой нетрадиционных отношений.
Шампанское с продавщицей хлебного отдела :-)
Большинство клиентов хотят коннекта в любое время, и практически любой продажник решит сам - отвечать ли только в рабочее время и клиенту это сообщить, либо все же дать личные контакты «ну вы мне пишите, а я заведу заявку как смогу поскорее».
Которые не помогут примерно никак. Клиент, обычно, работает не с конторой, а с человеком.
Клиент может не особо помнить, что там была за контора, а вот имя Васи и как без него стало плохо, очень даже помнит.
И Васе даже не нужна какая-то секретная база, он с улицы придёт к тем же клиентам, через официальные каналы
так база 500 клиентов копируется и уже из новой фирмы будут звонить - а потом докажи что ты их не собрал в Гугле
Мб оффтоп, но интересно узнать. Это действительно так работает? Я ситуацию на себя проецирую, кейс когда мне звонит знакомый продажник, говорит что он работает в новой фирме. Вероятность маленькая что я стану новым клиентом, даже если я знаю продажника. Как будто взаимодействия с бизнесом/брендом, при том долгие, не только в цену упираются.
Лично я ценю как качество услуг, так и надежность. Если цены рыночные или чуть выше, да как бы без разницы, нет смысла рыпаться. Я к чему накидываю, что если бизнес построен только на том что там низкие цены и ничего другого не может предложить, имхо это путь в никуда. Так же если я делаю новую закупку, это все же риски покупать что-то в новом месте.
А причём здесь цена? Если надёжный человек, то какой смысл ломать с ним взаимоотношения из-за смены места работы? Особенно когда речь идёт о продажах, когда кроме репутации продажника ничего по сути и не важно. Другое дело, если бы за ним на старом месте стояло огромное производство, а на новом бы его не было, но это не о продажах речь, и так бывает редко, потому что зачем бы ему уходить в худшее место.
У меня очень многие контрагенты меняли места работы, и сам я продолжал с ними работать. Да и сам я один проект вёл последовательно в трёх юридических лицах.
ну надежность понятие растяжимое. Продажник - ок. А закупщики в новой фирме какие?? А если они сплошной брак закупают? А как с постоплатой? Если в старой финдир разрешал, а в новой фиг??? Слишком много прочих.... которые не равны
Так всё это и должен выяснить продажник, и рассказать клиенту. И убедить клиента работать с ним дальше, "потому что тут всегда поставки вовремя, контроль качества офигенный, ..., не то, что в предыдущем месте, я поэтому сюда и перешел, чтобы своим клиентам всё в лучшем виде мог делать..." И очень часто это чистая правда, редко продажники переходят в компании, где всё хуже, чем было на предыдущем месте.
И условия оплаты клиент будет обсуждать не с финдиром лично, а как раз со своим менеджером по продажам. И он уже будет для клиента согласовывать со своим руководством какие-то нестандартные условия договора, возврат брака, скидки за объемы и т.д.
Поэтому хороший продажник, куда бы он не перешел, уведет всех основных клиентов за собой. Потому что клиенты знают, что этот человек всегда вовремя пришлет все документы, всё подробно объяснит, если что-то пойдет не так - всегда поможет и решит проблему в пользу клиента и так далее. А вот будет ли это всё делать для клиента новый менеджер в старой компании - сильно большой вопрос.
редко продажники переходят в компании, где всё хуже, чем было на предыдущем месте.
не хуже --> для продажника, а не для клиентов
если у продажника 50% с продажи премия, но процессы черти какие и на клиентов плюют (и их довольно много) или 5% премия и процессы красивые, все за клиентами бегают...и их полтора человека... то что не уйдет он на новое место? уйдет и утащит клиентов и бабла нарубит пока клиенты не офигеют и не пойдут обратно (или не пойдут, на стороне клиентов тоже люди не всегда мотивированы чтото делать)
скажете продажник пойдет там где ему хуже чтобы клиентов радовать?
p.s. я недолюбливаю продажников тем что они мыслят кипиаями своими, от этого у них часто эмпатия отказывает напрочь..и истории что хороший продажник клиента не отпустит - это правда, но он это делает сугубо из за бабла которое клиент ему приносит, а уж какой кровью клиенту эта сделка дается - продажнику плевать
не хуже --> для продажника, а не для клиентов
скажете продажник пойдет там где ему хуже чтобы клиентов радовать?
Я не говорю об условиях и % за который работает продажник, это опять же вопрос его договоренностей с руководством. Я говорю про товар или услугу, которую собственно продают. Чем они лучше/качественнее, тем проще продажнику их продавать, больше продаж, клиентов, больше доход. Понятно, что это слишком общие рассуждения, и в каждой сфере есть куча своих нюансов.
это мало того что коммерческая тайна
Далеко не везде и не всегда. Оформление режима коммерческой тайны - это отдельный квест и не все им заморачиваются. Это же надо оформить определённые приказы, составить списки, назначить ответственных и т.д., и т.п., и пр. Что интересно, "нанесение на материальные носители, содержащие информацию, составляющую коммерческую тайну, или включение в состав реквизитов документов, содержащих такую информацию, грифа “Коммерческая тайна”. То есть, если вы относите данные контрагента к коммерческой информации, то на всех договорах, счетах, бухгалтерских документах, где фигурирует этот контрагент должен стоять соответствующий гриф и все, кто может по служебным обязанностям увидеть данные контрагента должны быть в списке работающих с коммерческой тайной.
иногда это невозможно чисто экономически...
трудно не согласится, имхо практически в любой "конторе" выбор между поднять зарплату васе и убавить зарплату секретарше (или вообще не дай бог себе), выбор будет однозначно не в пользу васи.
Мы замерили: каждый новый разработчик в первую неделю задаёт в среднем 12 вопросов, ответы на которые должны быть в системе, но хранятся в Confluence, Google Docs, корпоративных мессенджерах или в головах коллег.
Объясните, что такое эта "система", если даже хранение информации в Confluence представляется плохой практикой по сравнению с хранением этой же информации в "системе"?
Документация, это не решение проблемы ухода ключевых людей. Это страховка с франшизой. Она смягчает удар, но не предотвращает его. Настоящая защита от низкого bus factor не вики, а ротация задач, где никто не владеет модулем монопольно с обязательным код-ревью, контекст распределяется между 2+ людьми и тесты как документация, чтобы падающий тест показал, зачем нужен хак. Без этого любая база знаний, это красивое кладбище решений, принятых людьми, которых уже нет в команде.
Хорошо сказано. Помимо этого, база знаний со временем имеет тенденцию превращаться в хранилище устаревших, неполных, неконсистентных документов, которые мало кто хочет актуализировать. В результате теряется смысл, т.к. ей просто нельзя доверять. Т.е. всё равно, прочитав статью в базе знаний, приходится искать условного Васю или того, кто с ним когда-то работал, чтобы узнать, "это всё ещё так? или уже не так? и к какой версии продукта относится?".
Ротация — это попытка выехать на халяву, уложив в одну голову понимание нескольких задач «типа без потери эффективности». Просто совам-эффективным-менеджерам очень сложно принять, что skeleton crew — это не норма. Это предп**дечье, за которым неизбежно будет пи…, если не принять мер по найму какого-то резерва, который будет и учиться, и вовремя задавать вопросы из оооочень разумного уточнения про «имеет тенденцию превращаться в хранилище устаревших… документов», потому что всякая база жива только тогда, когда ей пользуются как минимум один «писатель» и один «читатель».
Разумеется, в хорошо организованном процессе ученик обладает поверхностными знаниями по нескольким вики-темам от гуру. Поэтому «в случае чего» можно из 2-3 учеников выбрать того, который может забить на остальные темы и углублённо долбать одну из тех, в которых он раньше был чисто на уровне «ну сними мне калибровки для вольтажей 12-45» и у которого понимания хватало только для того, чтобы знать, что такое калибровки, где эти вольтажи, и, главное, почему именно 12-45 (а вот самостоятельно ответить на вопрос «с какого до какого калибровать при данной симптоматике» может только гуру, ученик понимает, что стандартного 14-89 будет много, но 12-45 или 14-87, без длительного копания базы знаний не ответит).
Я их за глаза ласково звал когда-то «липами» (линейный инженерный персонал, то есть общее понимание — как у инженерного, задачи — как у линейного, при необходимости могут прокачиваться и от «понимания сделанного другими» переходить к самостоятельным разработкам).
За процесс ротации ставлю огромный плюс. У меня на работе команда Platform/DevOps инженеров поделена на две. Одна занимается разработкой, другая RUN деятельностью. Раз в два квартала люди переходят из одной команды в другую по 1-2 человека.
Какие плюсы могу отметить:
Качество и технологичность решений выросла, потому что одна команда разрабатывает автоматизацию, а другая ее эксплуатирует. Часто бывает что человек который делал решение, поюзав его в RUN деятельности видит недостатки и рождаются идеи для улучшений
Как сотрудник, я себя чувствую замечательно, потому что рутина уходит при ротации. Хочешь не хочешь, а все равно привыкаешь и встаешь часто в колею особенно в больших организациях, становится скучно
Каждый член команды может произвести аналитику из-за чего случилась проблема и завести хорошо проанализированный тикет в бэклог, потому что понимает как работает вся система в целом
Конечно, это не панацея. Есть сотрудники, которые показывают выдающиеся результаты в RUN задачах (по типу дебага istio), а есть те, кто быстро разрабатывает технические решения из-за прокаченных скиллов программирования. Но еще не было случая, чтобы кого-то вызывали из отпуска. Все получается решить без ключевых сотрудников (это те которые которые получают самые высокие оценки по итогам perfomance review из-за их влияния на проект), да не так быстро, но лямку тянем.
Минусы ротации выскажу одним тейком, не каждый хочет ротироваться, так как предпочтения в работе есть. Но у нас это обязаловка.
Так она поэтому и работает, что есть позиции «плац подметать» и есть позиции «картошку чистить». Некоторые предпочитают на воздухе, некоторые — на кухне, но в случае «обязаловки» все плюс-минус справляются.
Да вот только Васю с уникальными знаниями при таких позициях можно вырастить разве что специально, чисто из организационного мазохизма. А в ситуации, когда Кармак пишет движок, Ромеро — геймплей, а Петерсен — уровни, любая ротация «возможна» примерно как между нейрохирургом и конструктором ракетных двигателей.
Я бы в дополнение к твоему комментарию сказал что ротация нормально работает только в зрелых проектах.
Для кейса который ты описал, ротация это прямо антипаттерн, тут солидарен.
Огааа, когда велосипед уже в основном изобретён, дозрел до серийки и у нас есть линия насчёт Стриды, линия насчёт Аистов, линия насчёт Стелсов, линия насчёт электровелов для курьеров, отдел R&D насчёт продолжающихся изобретений всяких «двухскоростных фривилов Buffalo»… а стадия фон Дрейзе давно позади.
Тут прямо очень полезно регулярно примерить чужую шкуру не только для, но и просто для развития. Иначе есть риск закуклиться в варианте «педали назад = торможение» и до самого судного дня ничего не узнать про то, что это всё только про одну супер-минималистичную модель.
Страшно, когда этот антипаттерн пытается применить какая-нибудь эффективная сова, которая увидела, что есть «проблема Васи» и кинулась натягивать слона на вантуз. Формально диаметры подходят, но даже минимальный здравый смысл говорит нам, что это закончится фатально…
Встретил как-то на митапе начинающую программистку. Спрашивает, ты чем занимаешься? Я отвечаю: embedded в телекоме. А она меня спрашивает: это фронтэнд или бакэнд?
Это звучит красиво, а на практике задачи будут делаться значительно медленнее, потому что никто ничего толком не будет знать. Самого манагера это не будет устраивать, потом что его начальство будет спрашивать с него. Плюс это не очень хорошо влияет на мораль. Для многих его кусок - это его гордость, он старается делать его хорошо, переживает. Если же в стиле эксплуататора отобрать "прибавочную стоимость", то человеку становится все равно, он отчуждается от результатов труда и деморализуется.
Весь документ — 20 минут работы при принятии решения. Зато через полтора года новый разработчик не задаёт вопрос «а почему у нас RabbitMQ, а не Kafka?» — он просто читает ADR-012.
Прошло 10 лет с момента записи, и у нового разработчика может возникнуть вопрос - почему мы используем это легаси, а не продукт Х, который по всем характеристикам лучше этого и которого нет в сравнении?
почему мы используем это легаси, а не продукт Х, который по всем характеристикам лучше этого и которого нет в сравнении?
потому что надо обоснование, почему нужно затратить 100500 денег на переход с легаси на продукт X
если вопрос такой у когото возник - пусть он это обоснование и пишет..привлекая аналитиков, поднимая документацию, доказывая бизнесу что с новой системой мы будем обрабатывать не 5млн запросов секунду, а 5млн и еще 1000 сверху... а потратить надо на переход 100500млн денег и два года времени и неделю простоя прода
А потом окажется, что новые версии библиотек, где есть поддержка нового продукта, необходимого для интеграции, не поддерживают легаси продукт - всё равно придется с него слезать, но делать это в попыхах
есть такое дело, это проклятие кровавого энтерпрайза обычно
всё равно придется
для менеджеров это "есть сроки или непонятно когда в будущем"? если непонятно когда, никто ничего менять не будет
вон в США до сих пор на Коболе сидят.
но делать это в попыхах
а зачем делать это в попыхах? если бардак в планировании разработки..то тут ничего не поможет, и подход "работает-не трогаем" - самый правильный, а поменять линейным работникам обычно этот принцип (принцип - поясните выгоду бизнесу в течении года от ваших действий которые стоят 100500 денег) не под силу
для менеджеров это "есть сроки или непонятно когда в будущем"? если непонятно когда, никто ничего менять не будет
С этим будет разбираться уже следующий менеджер. Они же там меняются так же быстро, как и разработчики.
Йеп, у плохих менеджеров, которым нужна отчётность и которые набивают KPI, именно такой подход - если я не могу сейчас, то всё остальное становится «непонятно когда в будущем». И не надо кривых примеров о том, как кто-то будет сидеть годами и делать хз что, без выхлопа. На деле вопрос, обычно в разбросе нескольких месяцев, просто экстрасенсов нет.
Типовой сценарий, окей переходим на Х... Останавливаем развитие старой системы, вот вам 2 года, собирайте команду, делайте. Проходит год, инициатор перехода на "Х"-технологию с высокой вероятностью сваливает в следующую компанию (жертву), самой команды по факту нет. Пришедший на место старого инициатора новый сотрудник начинает убеждать, что технология "Y" круче, а "Х" уже старый не оправдавший надежд подход.
Это кстати типовой сценарий в загородном строительстве. Каждый новый строитель, найденный для исправления косяков предыдущей бригады, начинает часто свое становление именно с фразы - "кто так строит!!!? тут надо все переделывать!".
У нас дофига спецов, которые готовы написать все с нуля и свалить в закат не дожидаясь результата. И очень мало которые готовы поддерживать и развивать ранее написанное, чтобы вложения наконец-то стали приносить прибыль.
В соседней статье удачно показано как Васю найти!
у вас есть ADR в проекте? Или знания всё ещё живут в головах?
В моем случае, весь проект (созданный с нуля, учет на производственном предприятии) жил только у меня в голове. Попытки поделиться знаниями – были, я никогда не отказывал, но желания осваивать программирование у народа не было. По штату, у нас было несколько программистов, но, реальным, я один.
Другие попытки были со стороны новой главбухши. Ей удалось перевнедрить мой «Учет ресурсов», на довольно бестолковую, типовую, аналогичную конфигурацию. Мне ее все равно пришлось сильно переделывать, когда мы, сначала, из Украины перешли в ЛНР, а, потом, в РФ. А вот с учетом и расчетом заработной платы и учетом рабочего времени ей повезло меньше. Она попросила и я ей нашел порядка десяти разных вариантов «зарплат», найденных, правдами и неправдами, в Интернете. Поставил ей на компьютер, но, адаптировать их под нашу фирму она не смогла.
Более того, я предложил ей вести параллельный учет «зарплаты» в «1С8х:ЗУП». Она согласилась, но, без особого «энзазизма». Как оказалось, «ЗУП» очень жесткая система, с ней хотя и можно, но очень тяжело работать, То, что в моей конфигурации делалось на «раз-два», в ЗУПе, надо было долго «плясать с бубном». Единственный смысл этой типовой мог быть только в какой-нибудь супер-пупер новой и сверхсложной внешней отчетности. Но, всю текущую внешнюю отчетность мне удавалось делать самому, а для более сложного случая, я готовил обработку (аналог типовой «Конвертации Данных») по экспорту импорту из моей конфы в типовую и обратно.
Однако не судьба. Сначала пришел новый собственник и начал постепенно подгребать весь наш учет под свой (тоже самописный), что послужило даже поводом посчитать, что я уже фирме не нужен и мне предложили перейти чуть ли на «лопату», с урезанием оклада в два раза. Что мне, почему-то, не понравилось и я решил, лучше, уволиться. Тем не менее, в угасающем режиме (в связи с перетоком одной системы учета в другую), она еще вполне поработала без меня, поскольку «девочки» знали, как управляться с программой. А, потом, фирму вообще ликвидировали, как не слишком прибыльную. Что даже немного жаль (не за себя, я уже не работал там, а за наших «девочек», им искать новую работу было труднее), в силу того, что мы ведь стали «Новым Регионом». Но, оказывается: «Ломать – не строить!» – это универсальный принцип.
Так что: «Все мы хороши, когда спим зубами к стенке!» :) .
Был я типа такого Васи. Просил давайте этого работника (Например Вову) ко мне в замы, он перерос уже свою должность. Нет, вот тебе Миша, у него вышка! Вышка есть, а мозгов нет) Собрал чемоданы и свалил в закат из этой конторы, так как достали звонки умного Миши по всякой фигне, которую я знаю, что знает Вова, но из-за такой фигни нифиг ему было, и я с ним согласен, помогать Мише
С "фактором автобуса" всё понятно, но обычно Вася уходит не под автобус, а на +100к в другую контору. И вот тогда внезапно выясняется, что вся магия держалась на его честном слове и костылях, которые только он умел подпирать
И при этом в этот же момент из той другой конторы приходит разработчик в нашу контору, на ту же самую сумму, на которую Вася ушёл в их контору. Потому что иначе актуализировать зарплату до рыночной слишком сложно или вообще невозможно.
вся магия держалась на его честном слове и костылях, которые только он умел подпирать
«Так фигли вы там сидите — забирайтесь на воздушный шар и уматывайте оттудова!» ©
обычно Вася уходит не под автобус, а на +100к в другую контору.
уходил ... а сейчас эти безработные васи плачут статьями "на 500 откликов ни одного ответа - пачаму!!11" на хабре и линкедине ...
Проблема bus factor'а решается тем, что у каждого Васи должно быть не меньше двух сменщиков соответствующего грейда, и все сотрудники не должны быть загружены более 80%, чтобы у них оставалось время на трансфер знаний. Если эффективный менеджер™ единственного в некоторой области сеньора загрузил работой на 120%, то никакие базы знаний не помогут.
С интересом послушаю о двух сменщиках, например, для Перельмана.
Ну, не обязательно именно Перельмана, но на некотором не особенно уникальном уровне квалификации уже проблематично воспроизводить индивидуальные знания. Хорошо, когда можно въехать в тему за 1 месяц, как у автора. Сложнее, когда нужно несколько лет.
Работа головой, она такая. Требует головы.
Да кто бы спорил. Я досадно часто сталкивался с менеджерами не понимающими, что иногда разработчик способен делать некоторую работу только потому, что лет пять учился по профилю, потом лет пять работал, осваивая полученные знания на практике, а после ещё лет десять специализировался в определённой области, они свято верили, что любые знания можно за месяц передать джуну с курсиков. Но в описываемых в статье случаях всё наверняка намного проще, и незаменимость Васи объясняется только тем, что менеджер умирает от жадности даже от размера Васиной зарплаты, надобность платить ещё два раза по столько же ради резервирования немыслима.
Вот сколько живу и работаю, сколько пытаюсь строить понятные системы, с документацией, а вопрос до сих пор крутится один - а чо Вася то ушёл?
Bus Factor, всё же, про какие-то неприятные внезапности, когда произошло нечто внезапное и, обычно, непоправимое
А у вас, походу, процессы не очень и вообще контора не очень хороших людей, которая пыталась ездить на Васиной шее, ничего не давая ему взамен, потому единственный работавший человек и свалил и документация вам не поможет
Справедливое замечание. Васе, между прочим, тоже не хочется уходить от нажитых знаний. Поэтому с некоторого момента скорее разные юридические лица будут строиться вокруг компетенций Васи, чем наоборот. А статья, соответственно, должна называться "Вася поменял организационную форму".
Поэтому управленцам, у которых 80% компетенций сосредоточено в одном сотруднике, можно напомнить скромное изречение Ломоносова: "Скорее академию можно отстранить от Ломоносова, нежели Ломоносова - от академии".
На самом деле в точку.
Сотрудники в большинстве своем вкатыши и студенты нанятые на 35к и очень неохотно повышаемые в зп и должности. Текучка постоянная и большая (после 1-2 лет работы и постоянных отказов в повышении люди уходят)
Да и Васи на проекте - лично выращенные, люди забитые и терпящие многое.
И все надеятся что по документации этого Васи вчерашние стажеры и джуны организуют адекватную поддержку проекта.
Да и Васи на проекте - лично выращенные, люди забиты и терпящие многое, не верящие что где то даже соблюдают ТК и повышение не надо выпрашивать на коленях и ждать 3 года.
не обязательно, я был (и кстати являюсь даже сейчас) таким Васей, я вообще не против всяких обязанностей нахватать, но не для того чтобы стать незаменимым, а для повышения собственной квалификации чтобы потом больше всего уметь и знать
Сейчас вот на текущем проекте, через кровь и слезы, буквально заставляю других людей вникать в то как работает сервис..и документацию вместе пишем и проблемы разбираем, чтобы если я уйду, было кому мое поделие поддерживать.... но вот явно вижу что кроме меня это никому не нужно ;) ни коллегам (ну Игорь то всё знает чо, у него можно спросить) ни начальству (он Игорь то всё знает и документацию написал)...пфф...ну ок, я пытался ;)
>и вообще контора не очень хороших людей
Именно так обычно и происходит. Сеньор есть, ему платят хорошую зарплату и премии, он тянет как вол целые участки. Но загружен на 120%, порой и по выходным (за двойную плату) работает. Рано или поздно наступает выгорание и он уходит в более спокойное место. А страдают сотрудники прежнего работодателя, пытаясь разрулить проблемы.
Какая уж там документация...
Мне видится, что проблема компании и статьи не в Васе а в посыле, что документы пишутся после кода...
Попробуйте работать по нормальному sdlc, сначала пишем требования, архитектуру и т.п. и только потом уже код =]
А если разработчик сам все собрал, сам все решил и написал, то проблема не в нём, я бы на его месте точно так же болт положил на документацию, мне хватило бы код писать)
Давайте чтоль изобретем togaf или itil, например
А все почему? Да потому что самый главный (директор, випи и тд) не шарит в теме. Вот поэтому будут Васи. И пусть будут
Зачем SimpleOne? Я в N писал все в onenote-блокноте. Копию скинул начальнику. Ухожу в отпуск/уволился - мне С.Н. звонит - П. М., а как решить такой-то вопрос? Я говорю, записная книжка, раздел такой то. Все решали.
Начиная с 1го абзаца, уже видно, что управленец не владеет ситуацией.
Управленец также не понимает, что опыт в документации не передается.
Управленец пролетает мимо с тегрм "читальный зал", почву что он не понимает смысла этого словосочетания.
ИИ убирает это трение.
Хорошая метафора. Но вместе с трением незаметно так уходит и сцепление)
Сейчас во многих фирмах на ключевых направлениях сидит по одному синьору Васе, который получает вполне хорошую зарплату, задаёт стратегию и тактику, знает продукт досконально. А остальные - стажеры и джуны нанятые за 50 тысяч. От которых не жалко избавиться и платить им больше не за что, да и никто и не хочет. Текучка среди них большая, а если кто-то задерживается надолго и растёт в компетенции, то повышать зарплату ему всё равно никто не будет, ибо начальство готово платить 300 тысяч только одному человеку, ведь и так всё годами работает, зачем повышать расходы?
Я для себя приметил одну особенность: если разрыв стажа в фирме между работниками по одному направлению более 3 лет, значит либо зарплаты низкие и вследствие этого текучка, либо фирма умирает и не нанимает молодых сотрудников. В любом случае, с таким подходом не может быть и речи о развитии, только о выживании. Какая уж тут документация?
Это как раз то, что отличает хорошие процессы в компании от плохих. В хороших физически не возможно (точнее, практически не возможно), чтобы все знания хранились в голове одного разработчика. Стандартный флоу такой - есть идея от бизнеса, за нее отвечает продукт менеджер, он знает что это и для чего. Желание происходит через согласование (бюджеты, сроки, ожидания, архитектурные моменты возможно и т.д.), каждый этап прохождения рождает артефакт - бизнес / системный аналитик это фиксирует, груммит и рождает конкретную задачу, что для чего и как. Все это вносится в доку, обновляется и в конфлюенсе, условном, все это должно хранится. И лишь из всего этого, идеи, эпика или как принято в конкретной команде рождается таска, в которую погружается тот самый Вася и реализует. И если есть подводные камни, какие-то моменты не учтенные, это повод уточнить у аналитика, продукта, прийти к пониманию и снова зафиксировать в доке. А обсуждение обычно также происходит в каком-то нормальном мессенджере корпоративном, в канале, треде, чате и т.д., связанном с командой / таской – смотря как реализовано.
В итоге как минимум три человека всегда в курсе нюансов - продукт, аналитик и разработчик, они хорошо понимают, а все остальные знают куда смотреть - дока и мессенджер / почта.
Если как-то иначе, то в компании есть к чему стремиться, в плане организации процессов. Но даже с таким подходом всегда есть bus фактор, особенно если уходит не разработчик Вася, а продукт или аналитик, но это уже другая история.
Просто нужно х2 "Вася". Митигирует риск потери ключевых компетенций, позволяет "Васям" жить человеческой жизнью с отпусками, больничными и декретами ))
Программист должен быть как микросервис.
Вас никакая дока не спасет.
Вы по 2 года жмотите индексацию/повышение сделать а потом еще и премии обрезаете.
Самая главная проблема сидит в кресле гендира, а вы все хором не замечаете слона в комнате.
В микросервисной архитектуре, где команды разделены по доменам, документация должна быть тоже иметь схожую структуру, а не быть монолитной как один документ на 80 страниц. Такие инструменты как confluence и ей подобные плохо ложатся на всё это.
Начнём с того, что когда ты приходишь в команду, то должна быть станица команды с краткой информацией по системе в который ты будешь работать и ничего лишнего. Далее тебе дают задачу в той же jira, например, реализовать новый метод и там есть ссылка на документацию. Как должна выглядеть сама документация?
Документация по этой задаче должна быть изолированной, в ней должна быть информация только относящаяся к этому методу и видны зависимости. Начнём со структуры:
Первое что должен видеть каждый это бизнес описание метода, например, клиент хочет изменять свои данные в профиле.
Второе это архитектурное обоснование, визуальная верхнеуровневая схема, например, вот система от которой приходит запрос, он попадает в наш сервис и информирует изменения в другую систему. Ты визуально видишь, что тут по rest приходит запрос и через kafka отправляется уведомление дальше.
В отдельном блоке указаны требования надёжности, какой RPS, время ответа и тому подобное.
Третье это описание самой логики внутри сервиса и если это rest метод должно быть описание контракта, наверное, по OpenAPI спецификации, для kafka возможно json схема.
Так же должна быть ссылка на требования по коду принятые в команде, для каждого требования и взаимодействия скорее всего должна быть ссылка на библиотеку и стандарты реализации.
Визуально это должно быть в виде отдельных блоков, но структурно. И например кто-то меняет требования надёжности и видит на какие методы это влияет и те кто читает доку тоже видят это изменение, оно должно подсвечиваться во всех связях каким-то цветом или иметь статус. Можно посмотреть эти требования до и после. Когда эту правку внедрят, то статус изменится. В документации тоже должна быть система контроля версий.
И получается что такую документацию должны писать как аналитик, так и разработчик/архитектор и далее можно собраться и пройтись по ней обсудить конечный результат. У неё тоже должна быть статусная модель, когда это только черновик и далее она должна быть связана с каким-нибудь гитом, где после реализации PR от разработчика это тоже было видно в доке.
Я стою у окна и глотаю слезы
Потому что больше его не будет
Это статья как создать систему документации, а Вась поставить на поток? =)
Что по мне - самая большая БЕДА в том, что заполнять базу знаний заставляют разработчика.
И беда это не столько разработчика - а в том, что его заставляют писать. Но он не пишет. Или пишет минимум, формально.
Как будто мало других заинтересованных людей, в том, чтобы база заполнялась.
На проходной надо обыскивать, чтобы не тащили все что могут. *
У нас в Java команде мы настроили чекстайл, что без JavaDoc (документация к классам, полям и методам) проект просто не билдится. Написание документации уже куплено заказчиком в сумму часов работ по фиче. В итоге весь код задокументирован и никакие Васи не нужны.
Ла-ла-ла-ла-ла-ла-ла! Ответьте на вопрос "Почему ушёл Вася?" ... Поэтому и нет документации!
Отделение компетенций от персоналий - одна из основных задач компании, особенно если есть задача масштабироваться!
И я когда-то писал про такого Васю)
Документация не поможет, если 50% it-шников в компании и года не выдерживают. Если в компании токсичная атмосфера, все сроки - это "вчера", и есть желание заменить всех ИИ, то никакие процессы вам не помогут. Если для компании сотрудники - это не ценность, а боты, то никакие умные решения не спасут, в т.ч. "хорошая" документация. Платите достойно, уважайте мнение коллег, и дружные команды начнут расти как грибы. Они сами избавятся от слабых игроков, обеспечат передачу знаний в команде и взаимозаменяемость. Иначе так и будете уповать на единичных редких - один на миллион - экспертов, типа "Васи", который вас устроит, и готов жрать ваш кактус. Но вечно кушать кактус не может никто, поэтому даже такой "Вася" с вами не на вчено.
Шел 2026 год. Вася шел лесом тоже. Сейчас достаточно весь его код сгрузить в клод и попросить агентов во всем разобраться и полностью 'простым языком' описать агентов что там есть. А 'Васе' простая рекомендация - бронировать заранее место на бирже труда. Пригодится. Именно с этим 'Васей' я и столкнулся. А пройдет еще пару тройку месяцев, клод вообще даже местных 'незаменимышей' процентов 90 оставит без работы. Таковы реалии. Говорю как бизнесмен
Я бы поржал если мой прошлый проект загрузить в агентов и простым языком попросить объяснить :)) универсальный математический оптимизатор производственных процессов для предприятий, там и простому смертному в бизнес логику вникать полгода даже при условии что код написан максимально тупо и доступно, там вся в фишка в бизнес логике которая завязана на процессы пром предприятий и описывается конфигурацией данных загруженных в правильной структуре..а это из кода самого софта это крайне неочевидно
Вы удивитесь, но с вероятностью в 90% Клод и это обьяснит. Вы же хотябы приблизительно в курсе процессов должны быть. Просто пишете промт простым языком как вы хто понимаете, и как должно работать. В плане анализа и математики агенты на Опусе вообще великолепны.
Если у вас в ИТ уходит ключевой Вася то собственнику стоит уйти из ИТ и открыть сеть палаток по продаже, ну не знаю, бытовой химии.
открыть сеть палаток по продаже, ну не знаю, бытовой химии.
Или не бытовой...
Можете ли поделиться вашим ADR для ИИ (если есть), ищу более удобный, чем собранный на коленке https://github.com/NativeMindNet/aikit/blob/main/aikit-en/.claude/commands/adr.md
Да тут даже не в Васе дело. Я пытался внедрить такую систему просто для себя, потому что есть вещи, которые решаются на уровне продукта вместе с другими разработчиками, а потом возникает вопрос: почему было принято то или иное решение? Почему сделали так, а не иначе?
Создал плагин для Obsidian, прикрутил к нему Claude и GitHub с документацией. Сказал людям, что вообще практически ничего не нужно делать: просто берёте и делаете скриншот мейла с решением и копипаст. Ну или, если решение обсудили устно, то просто за 10–15 секунд надиктовываете, что вы там решили и по какому проекту. А Клод сам находит нужные документы и обновляет все данные.
И что вы думаете? Никто вообще этим не пользуется! И у меня нет никаких рычагов заставить их это делать. Не потому, что они не хотят - просто забывают в пылу работы, и ничего с этим не поделаешь. Румына с автоматом к каждому не поставишь, да и делать этого не планирую.
Привет. Я тот самый Вася. Не программист правда, а QA Project Lead, который по совместительству еще немножко продюсер, дизайнер и иногда еще баг-фиксер.
Плюсов, кроме как "нельзя безболезненно для проекта уволить" (да и то сомнительно, когда в компании десятки проектов, и можно временно пожертвовать качеством одного из них) особо нет. Когда у кого-то из стейкхолдеров возникают вопросы по проекту - ответчик всегда ты. А если стейкхолдеры в разных часовых поясах - могут написать и во время вашего сна. Ни на выходных, ни в отпусках невозможно не быть "на работе". Выгорание рано или поздно обеспечено
Короче никому не советую такое. Ищите, кому делегировать, документируйте важные процессы, а изобретая что-то новое - берите в подмышку с собой коллегу с самого начала, чтобы после "изобретения" не пришлось мучаться и объяснять принципы работы человеку, который систему первый раз видит
С самого начала я рад за Васю . Долгихлет ему жизни . А ворам интелектуальной собсственности я бы не давал слова совсем.
Враки)
Я унёс беспроводную клавиатуру, USB-хаб и F51.0
Вася уволился — и унёс с собой 80% знаний о системе