Bear's Rambles | МЕДВЕДЬ ГОВОРИТ...

Deadlines. Руководителям посвящается

В последних нескольких текстах я упоминал, что не очень люблю понятие «дедлайнов». Надо уточнить: в самом слове нет ничего плохого, как и в его умеренном использовании. Отвратительное начинается, когда им начинают злоупотреблять. Встречали людей, которые фразой «дедлайн до …» сопровождают всё, что угодно, даже, блять, ожидание лифта? Вот про это я. Просто для справки, «deadline» - это буквально линия смерти. Применим совсем капельку художественного таланта и получим

Дедлайн – срок, после которого выполнение задачи не имеет смысла

Много Вам таких задач попадалось? То-то и оно. Понятно, что дело не в самом слове, а в смысле, который оно несёт. Устанавливая ярлык «сверхсрочно» на слишком большое количество задач, мы погружаем команду в хаос, ведущий к безразличию и выгоранию. Незакрывающиеся спринты по скраму, вечные «надо было вчера»… Всё это рано или поздно приведет к тому, что команда просто перестанет воспринимать абсолютно любые приоритеты. Еще одна срочная задача? Да не вопрос, поступим с ней, как с гайкой: покрутим на болте.

Но и что делать тогда? Вообще не ставить сроки? Если Вы руководитель и у Вас в голове появились такие вопросы, у меня для Вас плохие новости: руководитель Вы так себе. Потому что расставление приоритетов и установка сроков – это и есть одна из основных Ваших задач. Как грамотно донести их до команды. Сроки нужны и важны. Просто не делайте из них культ. Подчеркните приоритет очередностью выполнения. Очертите круг стейкхолдеров, чтобы обозначить важность. Проговорите последствия для компании, если задача не будет выполнена в срок. Да бля, даже слово «дедлайн» употребите, если очень хочется. Просто не каждый день. И не к каждой задаче. И даже не к каждой второй.

Если у Вас в списке постоянно есть «горящие» задачи, то это говорит только об одном: что-то в процессе разработки реализовано неправильно. В том числе и Вами.
👉Если в такие условия диктует бизнес – измените вводные. Скорее всего, в какой-то момент именно Вы позволили заказчику не оглядываться на разумные сроки и диктовать свои. Поменяйте правила. Научитесь выстраивать очереди.
👉Если проблема в том, что задачи буксуют в границах команды и, по итогу, сдаются «флажке» - разберитесь, что не так внутри границ. Возможно, стоит пересмотреть компетенции команды, приоритетных ответственных, чтобы люди занимались теми задачами, которые они могут выполнять максимально эффективно. Возможно, кто-то уже выгорел и пора отправить человека в отпуск.
👉Стройте нормальные отношения с командой, чтобы ими не надо было понукать с помощью страшилок, и когда на самом деле припрёт – команда сделает то, что будет надо, успев к реальному дедлайну даже то, что, казалось бы, успеть невозможно. Басню Эзопа про мальчика, который кричал «Волки!» слышали? Вот-вот.

#медведьразмышляет #deadline

Soft skills. Самодисциплина. Часть III.

Шаг#2. Овладейте джедайскими техниками.

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

1️⃣Планирование.
Не в джире, а тупо ручкой в блокнотике выписываю задачи на день. Не только рабочие. С последующим вычеркиванием, что доставляет немалое удовольствие. Все-таки визуализация – отличная вещь!

2️⃣Сортировка задач.
В виду собственных личных недостатков в роли ментата: я очень долго не то, что «запускаюсь», я долго просто просыпаюсь с утра, мое идеальное распределение такое
👉Начать с чего-то легкого, иногда даже оставляю со вчера. Протестировать или дописать пару строчек кода. Просто, чтобы вкатиться в рабочий день
👉Дальше приступаем к сложным/объемным задачам.
👉В конце дня час-два закрываем мелочи, чтобы мозг немного сбавил обороты, но при этом продолжать делать что-то полезное.

Это однозначно не вариант для всех. Если Вы в состоянии ебашить сразу с утра – берите все сложное на утро. Если, наоборот, вам, чтобы проснуться, надо еще больше кружек кофе, чем мне – занимайтесь чем-нибудь «ненапряжным» хоть до обеда. Я не продаю готовый метод. Я просто рассказываю, что работает и почему. А Вы уже примеряйте по себе.

Есть еще наблюдение: если попадается продолжительная задача, которая плохо декомпозируется на простое/сложное, а только на сложное и блять еще сложнее, то дня через 3 меня начинает клинить. Из-за отсутствия привычного ритма. Единственное, что придумал: разбавлять другими задачами.

3️⃣Сегментирование рабочего времени.

Разбивайте рабочий день на сегменты (я знаю два варианта): по времени («помидорки») или по задачам (специального названия не знаю, я и про то, что работа интервалами по будильнику называется не табатой, а помидором узнал только полгода назад)

Для тех, кто не знает, что такое помидорки: такой метод разбиения рабочего времени, когда ты сколько-то работаешь, сколько-то отдыхаешь. Называется он «pomodoro» в честь первого таймера в виде помидора, который применили к этому занятию. Не первому вообще, а первому, который еще потом описали в книжке. Или еще где, не ебу. Вообще бесит эта фигня, когда берут общеизвестный факт, придумывают ему название, выпускают про него книгу, продают курсы, а ты на это смотришь и удивляешься даже не людям, которые про это рассказывают с умным лицом, а тем, кто после рассказа кричит ура и чепчики бросают.
В общем суть вы поняли. Классическим (в смысле на том самом помидоре нарисовали маркером) считается сочетание минут 25/5, вроде как. Я, методом научного тыка, понял, что мне подходит час каждые 10 минут. Час работы😊 В любом случае, опять же – это очень индивидуальная штука. Подберите себе свой интервал. Ну и да, я не работаю каждый день на таймере. Это, скорее, способ дать себе пинка, когда работать очень не хочется.

Когда мы привязываем интервалы к задачам, возникает сразу несколько проблем
🔘проблемы времени
👉не каждая задача вписывается в удобный нам интервал
👉не каждая задача декомпозируется на подзадачи, которые вписываются в удобный нам интервал
то есть, мы рискуем получить интервалы длинной в 4-6 часов, в рамках которых сложно поддерживать концентрацию
🔘проблема перезапуска – когда я привязываюсь окончанием интервала к окончанию задачи, получается, что я начинаю рабочий день столько раз, сколько у меня задач за день. А мне и первый дается с трудом. Плюс, перед новой задачей всегда есть соблазн «погулять» чуть подольше, потому что «ну какая тут разница, начну я сейчас или через 5 минут». Поэтому, в таком случае, я привязываю интервал не к окончанию задачи, а к процессу тестирования. То есть иду отдыхать перед тестами. Таким образом я не стартую рабочий день заново, потому что я еще в той задаче, а новая начинается уже после того, как я немного поработал (в целом аналогично первому началу рабочего дня), и меньше соблазн погулять подольше – задачу все еще ждут.

Вот такая история про повышение личной эффективности. Заебись? Отдельный тэг нада?

#медведьразмышляет #softskills

Soft skills. Самодисциплина. Часть II.

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

Шаг#1. Измените отношение к работе.

Я понимаю, что всем нам нравится представлять себя скорее художником, чем токарем. Без пренебрежения ко вторым и без восхищения первыми. Просто как факт. Но такой подход, как раз таки, оправдывает поведение сотрудника#2 из примера: у меня творческая работа, мне нужно настроение. Нееет, блять.

Разработка – это такое же ремесло, как и вытачивание деталей.

Чем скорее Вы это поймете, тем скорее Вы станете на самом деле крутым разработчиком. С осознанием того, что Ваша работа – ремесло, приходит необходимость совершенствоваться в ремесле, а не «я художник – я так вижу». В конце концов, история знает достаточно много творцов, которые умерли в бедности, в том числе и потому, что не могли творить РЕГУЛЯРНО. В целом, «творение» и «регулярность» не очень сочетаются. Вот Стивен Кинг, к примеру, который выдает в последнее время по книге в год, очень рекомендует относиться к писательству как -сюрприз! – к работе, а не творчеству. Стивен Кинг. Уловили? Обожаю, когда что-то не очень мной любимое, но очень популярное, служит для объяснения моих идей. Типа "ну хоть на это ты сгодился".

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

Продолжение следует. По фасту…

#медведьразмышляет #softskills

Soft skills. Самодисциплина. Часть I.

Предисловие. Опять мысль не влезла в один пост🤦🏻‍♂️ Поэтому их будет целых 3😂😂😂 Но друг за дружкой. На два не получилось нормально поделить по смыслу. Между постами минут 10 интервала, по крайней мере так выставлено в отложенных. Главное, чтобы ушли по очереди, а то мало ли, залагает где. Ну а теперь по тексту...

Еще один навык, напрямую влияющий на нашу эффективность, как разработчика (да и вообще любого специалиста), но при этом не являющийся измеримым – самодисциплина.
Правда, тут недавно стало модно выделять self skills – это все те soft skills, которые начинаются с приставки "само-", но я уж не буду.
Кроме непосредственного влияния на эффективность, способность заставлять себя работать может влиять и на выбор подходящего сотрудника для команды, или, наоборот, на выбор сотрудником той или иной работы. Давайте поясню любимым способом: на примере с двумя крайними точками.

Дано Два сотрудника
Сотрудник#1 не очень прокаченный в плане хардов, но очень ответственный и исполнительный
Сотрудник#2 гуру всего, что только возможно, но может пропасть на день-два легко
Оба типажа не являются редкостью в среде разработчиков, кстати. Первый сотрудник идеален для команды, работающей с преимущественно простыми задачами, но при этом критична скорость их выполнения (сопровождение, поддержка). Потому что такие команды не могут позволить себе выпадение специалистов из ежедневной деятельности. В ситуации же, когда разработка идёт "в долгую": новый продукта или функциональная область, там, где горизонт решения задач значительно удален, а сами задачи требуют лучших навыков, второй сотрудник будет предпочтительнее – срочных задач нет, дедлайны мерзкое слово, не люблю его известны заранее, а такой типаж как раз таки очень хорошо умеет некоторое время пинать тапочки по квартире, но собирается перед сдачей (части)проекта и успевает сделать все в последние сутки.

Так что заметка руководителям: подбирайте людей не только по знаниям, но и по соответствию "рабочего" темперамента условиям разработки, которую вы ведете. А то знаю такие ситуации, когда берут на работу сильного специалиста, но сажают его в сопровождение. А ему тупо неудобно, когда над душой стоит контролёр и «да блять когда уже будет готово, надо срочно в прод».

Ну и человек, прокачавший и самодисциплину, и hard’ы, будет предпочтительнее всегда. Вот и поговорим, как стать таким. По крайней мере, со стороны самодисциплины.

Продолжение следует. По фасту…

#медведьразмышляет #softskills

Джо Аберкромби. «Земной круг»

На этой неделе сразу 10 книг в рекомендации!

Аберкромби (блять, хер напишешь без ошибок, поэтому дальше будет Джо, не надо такие фамилии заводить) – относительном молодой (дебютная книга вышла в 2006 году) британский писатель-фантаст. В стиле фэнтези. В стиле темного фэнтези. Ну, по крайней мере, цикл «Земной круг», о котором речь – точно темное.

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

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

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

👉Трилогия «Первый закон»
1. Кровь и железо
2. Прежде чем их повесят
3. Последний довод королей
👉Отдельные книги
4. Лучше подавать холодным
5. Герои
6. Красная страна
7. Острые края (сборник рассказов)
👉Трилогия «Эпоха безумия»
8. Немного ненависти
9. Проблема с миром
10. Мудрость толпы

В целом, весь цикл получился очень ровным, есть книги, которые мне понравились чуть больше, есть те, которые чуть меньше. Но, по моему мнению, ни одна не опустилась ниже определенного уровня. Это большая редкость для такого длительного цикла. Тут яркие примеры — это «Хроники черного отряда» Глена Кука (несмотря на статус культовых в жанре темного фэнтези, с какого-то момента читать вообще не возможно) или Пространство/Экспансия Джеймса Кори (тоже вовремя не смог отпустить дойную корову).
В общем, очень плотный и качественный цикл. Оценки на Литрес тоже это подтверждают – диапазон на все книги 4.7-4.8.

Другой дело, что в какой-то момент стилем автора «наедаешься». У меня на чтение ушел год, но не потому, что я медленно читаю, а просто приходилось делать перерыв. Бывает такое. Вроде и сюжет интересный, и излагает недурно. Но все равно думаешь «не, давайте в этот раз что-то другое».

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

В общем, Джо удалось в достаточно простых декорациях создать очень самобытные произведения. Как циклу дам 10 из 10. Некоторые книги (какие не скажу, читайте и составляйте собственное мнение), можно оценить на 8, но именно как цикл – это редкая история, когда все на очень хорошем уровне.

P.S. Если что, фото взято из открытых источников

#медведьрекомендует #почитать

Soft skills. Коммуникативные навыки. Зачем и как?

О блин, чуть не забыл. Давайте какие-нибудь такие общие слова, вообще зачем нам коммуникация и как ее развить.

Итак, «Зачем?»

➕Положительное влияние для Вас лично
👉Позволяет активнее строить карьеру
👉К Вашему мнению чаще прислушиваются (особенно чаще, если сравнивать с тем, что Вы его вообще не озвучиваете)
👉Проще получить нужную информацию

➕Положительное влияние для команды в целом
👉Упрощает обмен идеями и знаниями
👉Создает комфортную атмосферу

Ответ на вопрос «Как?» обычно не очень отличается от советов врача по разработке ноги после серьезной травмы: «ну больше ходите, двигайте там ей». И если необходимость навыка перемещения тела в пространстве нами обычно не ставится под сомнение, то про общение многие думают «не жили красиво – нехер начинать». В смысле "мне и так норм, зачем мне лучше коммуницировать с коллегами?" Поверьте, будет еще лучше.

Поэтому попробуем обойтись без советов «чтобы больше общаться – больше общайтесь» и все-таки попробуем вывести какие-то базовые практические советы.
1️⃣Не ссыте. Есть идея – смело выдвигайте. Но будьте готовы ее защищать. Есть вопрос – спрашивайте. С каждым новым повторением будет становиться проще. В целом, в нормальном коллективе вас не будут сразу бить ссаными тряпками.
2️⃣Выберите для себя удобную роль, если угодно маску. Не мрачного молчуна, все-таки мы говори про общение. Главное, Вам в этой роли должно быть комфортно. Ну или наименее дискомфортно. Если Вам кажется, что эта роль через чур «мудаковата», предположим, не переживайте. Можно быть мудаком обаятельным. У меня вот отлично получается. Ну быть мудаком уж точно, а вот про обаятельного надо спросить на всякий случай.
3️⃣Больше читайте. Любой литературы. Это помогает четче и быстрее выстраивать мысли на практике.
4️⃣Обязательно фантазируйте на тему «а что стоит сказать в той или иной ситуации?» Рано или поздно Вы можете попасть в ту или иную ситуацию
5️⃣Для начала старайтесь излагать мысль максимально чётко и кратко, со временем увеличивайте количество слов. Понятно, что в зависимости от ситуации: даже если вы прокачались до уровня «Цицерон», не стоит в условиях цейтнота задвигать полноценную речь.

в общем, пробуйте. В какой-то момент это становится даже весело.

#медведьразмышляет #softskills

Люди и херня, которую они несут.

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

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

Почему так?

Люди, за редким исключением упоротых идиотов, несут херню сами не понимая, что они несут и делают это по двум причинам
1️⃣Человек делает это осознано, но при этом не понимая, что это херня. То есть он сходил к определенному источнику, считая, что мудрости, сложил рядом с ним ладошки в кружечку, ну как в детстве делали, когда пили из колонки, набрал хуйни под краешек и аккуратненько, чтобы всем побольше досталось принёс Вам
2️⃣Человек просто оговорился, бывает, со мной тоже, ничего страшного. В запаре перепутал лево с право, ночь с днём, ну или огурец с членом (со мной такого не случалось, но мало ли). Но при том, что оговорка вполне очевидная, эта самая херня может отложиться в башке как зафиналенный результат, хотя в моменте все имели в виду другое.

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

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

Так что не бойтесь, не стесняйтесь и не пускайте на самотёк: говорить людям, что они несут херню надо и, иногда, абсолютно необходимо

#медвежьиинсинуации

Soft skills. Объяснение концепции на примере коммуникаций.

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

Вопрос #1
❓Почему я начал с коммуникаций?
Ответ
👉Достаточно простой: большинство людей интуитивно и не совсем верно понимает под софтами именно умение выстраивать отношения.

Как-то так повелось. Соответственно, на таком примере можно проще показать границу, которую я хочу исследовать: когда, как и при каких условиях soft skills переходят в hard skills.

Вопрос #2
❓Какое главное отличие soft skills от hard?
Ответ
👉Где-то на базовом уровне я бы сказал, что измеримость. Hard skills мы можем проверить или подтвердить.

И, в такой трактовке, переход soft в hard невозможен априори. Мы можем эмпирическим путем проверить знания по какой-либо технологии. Но, чтобы оценить способность к коммуникации, мы всегда вынуждены опираться либо наши впечатления, либо на отзывы о предыдущем опыте. И то, и то – субъективно. А во втором случае мы, вдобавок, полагаемся на ЧУЖОЙ субъективный опыт, считая, что если человек в N различных коллективах проявлял чудеса коммуникабельности, то проявит и в N+1. И тут мы вообще вступаем на территорию скользкого инструмента под названием «математическая индукция». А с его помощью, как известно, можно доказать, что все лошади белые.

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

То есть, если какой-то навык позволит сотруднику значительно более эффективно выполнять свои обязанности, то это – hard skill. Да, оценка все равно останется субъективной. Но мы вводим критерий не количественный, а качественный. И тут без особых проблем даем однозначный ответ.

Давайте порассуждаем.

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

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

#медведьразмышляет #softskills

Кип Торн. Интерстеллар: наука за кадром.

Вторую неделю подряд в нашей избе-читальне книга от нобелевского лауреата, теперь правда не по литературе, а по физике.

Да, я задержался с прочтением этак лет на 10, но что-то все руки не доходили. Рад, что наконец дошли.

Я обожаю «Интерстеллар». Кип Торн оказался не сколько научным консультантом, сколько идейным вдохновителем фильма. «Наука за кадром» — это увлекательное путешествие по истории длинной 10 лет о создании фильма, который будет проходить по грани между доказанными научными фактами и дикими, но обоснованными предположениями. Каждая идея в фильме должна была иметь под собой научное объяснение. Параллельно рассказу о том, как продвигалась работа над фильмом, преимущественно его научной частью, Кип Торн погружает читателя в теорию того, что режиссер и команда спецэффектов воплощала на экране.

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

#медведьрекомендует #почитать

Soft skills. Оправданное лидерство. Часть II.

У Вас где-то здесь должен возникнуть вопрос: Медведь, а как же так? Разве не бывает так, что ну вот никак не успеть? Отвечаю: в моей практике таких ситуаций было от силы 1-2%. Когда ни оптимизацией собственных ресурсов, ни ограничением MVP, ни привлечением сторонних проблему не решить. И все эти ситуации были связаны с проебами на более ранних этапах. Я в таких случаях обычно принимаю решение о переносе MVP, потому что я не фанат дедлайнов (опять же – где-то есть отдельный текст про это, и он выйдет, зуб даю).

И тут у Вас возникает следующий вопрос: а в чем тогда, блять, разница? Разница в том, что ситуация разобрана, решение оправдано, логически и эмоционально. И, если Вы работаете не с полными идиотами, то через 1-2 повторения они запомнят подход и начнут работать по нему сразу, минуя стадию воплощения ада на Земле. А что является главной задачей руководителя (как его не назови, начальник отдела, тимлид или еще разными словосочетаниями)? Правильно

сделать так, чтобы люди обходились без него.

И не путем, как многие думают, бросания ребенка в ванну, чтобы он научился плавать, даже не проверив что там не плавиковая кислота. Неееет, блять. Это не так работает. Вы должны показать путь. Пройти его. И тогда – это называется обучением. Это называется лидерством. А без этого…. Ну… Вы просто рукой водите и всё. Если Вы понимаете, о чём я😜

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

Если Вы уже руководитель, то подумайте - а точно ли Вы лидер? Если ответ "да", то лучше спросите своих подчиненных. Бывших. Если Вам не ответили - то ответ точно не "да"😂😂😂

Если Вы все еще на пути к должности, то можете стать таким. Если не руководителем, то лидером. Главное не ссать. Но об этом тоже в какой-нибудь следующий раз.

Продолжение следует…

#медведьразмышляет #softskills

Soft skills. Оправданное лидерство.

Странный заголовок, согласитесь?
Но, с другой стороны, подумайте и ответьте на вопрос:

А все ли Ваши руководители были лидерами?

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

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

Попробую привести обобщенный пример «по мотивам» ситуации, которая часто возникала вокруг меня. Но для начала нам надо (для не айтишников) ввести понятие MVP (Minimum Viable Product) – минимально жизнеспособный (лучше подходит непрямое работоспособный) продукт – процесс создания продукта или отдельной функциональности с минимально необходимым набором функций для проверки его жизнеспособности, получение пользовательского отклика, способности закрыть «боль». Если вы знаете что это или уже поняли, можете не жмакать на скрытый текст. Для остальных под катом более простое объяснение

MVP – это когда вы приезжаете к деду на дачу, а он говорит:
-Да что вы вообще городские в огородах понимаете. Даже грядку вскопать не сможете!
И вы, в праведном гневе, хватаете лопату и пару раз тыкаете ей в землю, «вот, старый, смотри!». Победа одержана, Вы доказали, что справится с грядкой Вы в состоянии и пребываете в такой эйфории, что, в общем-то, похер, что дед смотрит на вас охуевшими глазами, потому что вы только что порубили клубнику. Примерно такой же смысл и в MVP.

Итак, лирическое отступление закончено, вернемся к примеру (все совпадения выдуманы, персонажи случайны)

❗️Ситуация. В обозримом и неотдаленном будущем необходимо сдать MVP для которого, мягко говоря, не все готово.

💩Исполнитель(и): бегают с горящей жопой по кругу и орут, что все пропало. Если их несколько, то могут еще орать друг на друга.

👑Руководитель.
🟢Принимает волевое решение перенести презентацию MVP (добрый понимающий человек, не очень хороший руководитель)
🟡Выдает ценное указание «надо приложить все силы» (возможно выступит как понимающий и добрый человек, но уверенный руководитель)

🤝Лидер
1️⃣Соберет отдельную встречу (если это происходило на общей)
2️⃣Выяснит уровень расхождения реальности от ожиданий
3️⃣Распределит задачи по имеющимся исполнителям
4️⃣При необходимости наберет 911

В рамках решения ветки «руководитель» люди продолжают работать с горящей жопой и в состоянии дедлайна (о вреде дедлайнов мы как-нибудь еще поговорим), просто не бегают при этом по кругу и не орут матом. Ну или бизнес не увидит MVP в срок. Похер, терпимо.

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

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

Продолжение следует … По фасту.

#медведьразмышляет #softskills

Уинстон Черчилль. Вторая мировая война.

Мне тут на неделе удалось посоветовать хорошему человеку хорошую книгу, которую он не читал. Всегда такое радует. Ну и заодно решил: может еще кто не читал? Так что стряхнул пыль со своего старого отзыва, подрихтовал, получите-распишитесь.

В плане оценки WWII Черчилля для меня соткана из противоречий. Она одновременно написана очень интересным языком, но в то же время читается невероятно сложно (авторский текст перемежается официальными письмами, докладами и статистическими данными). В этом плане я бы поставил её на второе место, если убрать из рейтинга вузовский учебник по матанализу. «Сто лет одиночества» Маркеса все еще уверенно на первом.

Труд, а мне все-таки кажется, что это слово тут более применимо, чем «книга», имеет, как свои очевидные плюсы, так и очевидные, жестко привязанные к плюсам, минусы.

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

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

👉Это история, пропущенная через призму абсолютно другого культурного кода. Для нас события WWII – это либо героическая смерть, либо героическая победа. Для Черчилля это, скорее, героическое выживание.

Все это очень непривычно, мы привыкли смотреть на историю WWII по-другому. С другого ракурса, с другими установками. И именно этим ценно.

Вердикт я могу разделить на две части.

✔️Мой персональный. Если у меня когда-то будет книжная полка, которую я буду заполнять самостоятельно, то эта книга точно попадет в топ-10 того, что я захочу на нее поставить. Хотя бы блин просто как трофей в духе «Я это сделал».
✔️Ответ на вопрос «стоит ли ее читать?» Если у вас есть интерес к истории и готовность ради этого интереса страдать - да. В остальных случаях, если только не хотите козырнуть знаниями на школьном уроке истории – нет.

#медведьрекомендует #почитать

Soft skills. Построение отношений.

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

Small talk.

По-русски будет примерно, как «пиздеж ни о чем» «досужие разговоры». Очень важный навык для руководителя: через короткие разговоры на отвлеченные темы очень легко задать команде нужный настрой.
Да, с массовым переходом на удаленку, small talk частично растерял время и место, в которых он может проходить. Но
1️⃣ не до конца
2️⃣ с учетом тенденции к возвращению людей в офисы хотя бы на гибрид, вернёт свою важность.

Если Вы начальник и не умеете выбирать темы, заводить подобные разговоры – у Вас проблемы. Это лучший способ незаметно прощупать и поправить настроение коллегам.

Да, блять, это манипуляция и фу-фу-фу🫤 Но, будучи руководителем офисной команды, я, каждый раз по дороге на работу, вспоминал, иногда придумывал или тасовал факты, выбирал в меру острую тему. Чтобы, пока народ наливает себе первую кружку кофе и пытается собрать себя с утра в кучу, помочь им с этим, взбодрить оживленной беседой. Задать темп дню. Работало всегда. Конечно, когда я как-то об этом проговорился, меня назвали «мудаковатым манипулятором», зато сделали это с уважением. И пониманием ценности подхода. Если Вы сами не умеете или не хотите – заведите себе в команду человека, который умеет. Еще один вариант, если хотите, чтобы команде всегда было о чем поговорить – подбирайте людей по интересам.

История #1. Случилась со мной. Как-то раз мне отказали по итогам собеседования по причине того, что вся бригада у них была то ли из толкиенутых, то ли еще из каких-то ролевиков. В какой-то момент даже выяснилось, что первые два тома свободного продолжения от Перумова мне нравятся больше, чем оригинал Дж.Р.Р. Толкина… Я думал прям там заорут «ты не пройдешь!». Посохом бы еще отпиздили, да собес был онлайн.

История #2. В давние времена один мой знакомый, даже не из IT, если что, набирал себе в команду только автолюбителей. Причем чем хардкорнее – тем лучше. Ясно, что профессиональные навыки тоже были важны, но попасть к нему, не будучи автолюбителем, было почти невозможно. Мотивировал он это как раз таки тем, что «всегда должны быть темы для разговора»

Темперамент общения.

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

В целом такая же ситуация и на собеседованиях. Люди, почему-то, часто стремятся показать себя не такими, какие они есть🤷‍♂️. Вопрос темперамента общения, я хз, как еще это назвать, мб подскажете кто-нибудь, невероятно важен.

🔵Если в команде принято общение через «Вы» и «будьте любезны», человек, привыкший работать в состоянии, когда он перманентно послан/посылает нахер, будет чувствовать себя некомфортно. Знаю случай, когда подобный мезальянс закончился быстрым разводом. Так что экономьте деньги и время.
🔵И наоборот. Если у Вас считается нормальной токсичная атмосфера, то не стоит брать человека, который на собеседовании с Вами общался цитатами из Достоевского, Хайяма или Алексея Толстого.

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

Продолжение следует…

#медведьразмышляет #softskills

Soft skills. Исследование на тему «Когда мягкое становится твёрдым» без ссылок на порнохаб.

Если честно, на вторую серию постов я планировал кое-что другое, но за последние несколько недель я узнал пару фактов, касающихся прошедшего ивента Инфостарта это такое сообщество (сайт, компания, комьюнити) 1Сников :
👉Там был круглый стол или открытый микрофон, что-то из этого, на тему «что важнее soft или hard»
👉Доклад на тему soft skills залетел в топ-20 из 129 докладов

Интерес сообщества к софт скиллам вроде как понятен: сложно не думать о софтах, когда

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

Да, все эти клише про разрабов-нелюдимов не то, чтобы прям клише. Кто-то с ним борется, кто-то уже поборол, а кто-то думает, что он и так хорош. А вот хер. Нет. Разделение на софт и хард кажется уже не очень актуальным. Некоторые из софтов – это про базовые навыки, необходимые для нормального выполнения своей работы. Без некоторых других невозможен карьерный рост, как таковой, выше определенного предела. Еще одна часть в какой-то момент станет, по сути, Вашими прямыми должностными обязанностями. И все это будет так или иначе влиять на то, подходите Вы на определенные позиции и в какие команды или нет.

Поэтому, как только вы начнете понимать

Софты – это такие же обязательные навыки, как и харды

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

Уже привычно этот первый пост в серии является скорее затравкой и настраивает на нужный лад. Дальше мы пройдемся по укрупненной группировке софт скиллов, поговорим, как их можно тренировать. Рассмотрим, когда, как и какие из них должны влиять на формирование команды. А также какие подводные камни могут ожидать Вам в зависимости от наличия или отсутствия разных софтов у Вашей команды.

Будет интересно. Или нет. Расскажете потом.

#медведьразмышляет #softskills

Legacy. Путь здоровых изменений.

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

Вот мы потихоньку и подошли к самому главному: что делать, если Вам досталось наиболее классическое legacy в виде эволюционирующей системы в Вашем стеке технологий?

Я вижу два развития событий:
1️⃣ У Вас до жопы времени и никто не торопит с внедрением новых фич
2️⃣ Новые фичи бизнес хочет каждый день. Ну или через день.

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

Но. Придерживайтесь следующих шагов
👉Выделите функциональность системы, которая напрямую связана с новой задачей. Вот прям напрямую. Не зависит, не является основанием. Упрощая: вам надо изменить цвет кнопки с зеленого на красный. Это влияет только на кнопку. Кнопка – это та область функциональности, которую мы хотим поменять. Ничего не должно измениться в работе системы ни до появления кнопки на пользовательском интерфейсе, ни после
👉Вы определяете все, что имеет отношение к данной функциональности: пользовательские интерфейсы, кодовую базу, структуру данных и вообще все, что приходит Вам в голову.
👉Для выделенной функциональности Вы начинаете заново создавать описание, начиная с бизнес-процесса. Вы выясняете все тонкости и нюансы.
👉К полученному описанию Вы относитесь как к обычной задаче: создаете план разработки, реализуете его настолько максимально, насколько это только возможно. Тут мы должны понимать, что не все изменения можно внести безопасно для всех. Если Вам кажется, что в таблицу БД необходимо добавить новые индексы, Вы должны учитывать, что их перестроение может занять прилично времени. Если у Вас есть какие-то коннекторы к изменяемой функциональности, озаботьтесь, чтобы публичные программные интерфейсы работали с теми же входящими параметрами и возвращали те же исходящие данные. Ну и так далее. Все более-менее очевидные вещи, о которых люди любят забывать в запале. И, разумеется, в рамках решения этой задачи Вы учитываете все те вещи, о которых мы говорили где-то ранее: документацию, правильные принципы проектирования и бла-бла-бла
👉Вы сравниваете все, что реализовывало эту функциональность ранее с тем, что у вас получилось. Удаляете то старое, что перекрывается новым. git merge, короче говоря. Все, только что вы избавились от целого куска legacy-кода.

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

Очевидно, что такой подход займет больше времени, чем просто «вставить костыль для новой фичи», но он не приведет к усложнению системы в дальнейшей поддержке, вы обрываете цепочку накопления legacy в отдельно взятой функциональности. И таким образом через некоторое время покроете нормальным кодом, документацией, тестами всю систему. И вот тут наступает дзен.

#медведьразмышляет #legacy

Legacy. Старт с нуля.

По сути, единственная ситуация, когда от legacy необходимо избавляться на все 100%: смена стека технологий. Не важно, по какой причине, будь то уход разработчика (в том числе из жизни), смена команды, устаревание технологии, и прочая… Важен результат: технически сопровождать систему некому.

Если так случилось, все же предварительно убедитесь в двух вещах:
1️⃣Описываемый системой бизнес-процесс в целом требует изменений (справедливости ради, это вообще главный вопрос, который нужно поднимать в любом случае)
2️⃣В Вашем распоряжении есть люди, которые вообще понимают процесс, заложенный в систему.

Серьезно, в моей карьере было два случая, когда меня попросили переписать систему под 1С 8.х в ситуации, когда предыдущий разраб ушел из компании «с концами». И людей, которые бы помнили, какую логику закладывали в работу системы, не осталось. Ну точнее остались, но «слушайте, это так давно было, уже и законы (ЗАКОНЫ, КАРЛ!!!) поменялись»... Один раз это было с 1С версии 7.7 (и это еще было терпимо), второй – с FoxPro (и, если ад существует, это мне зачтется как понижение температуры в котле хотя бы на пару градусов).

👉Если ответ на первый вопрос «нет» - забейте болт и живите счастливо.
👉Если ответ на первый вопрос «да», но на второй - «нет, то мне Вас очень жаль. Напишите письмо детям на случай, если падете в бою.
👉Если на оба вопроса вы можете ответить «да» - смело приступайте.

Главное помнить: это новая система. И подойти к ней надо со всей ответственностью, как к новой системе.

#медведьразмышляет #legacy

«Определенно… Тщеславие – мой самый любимый из грехов»

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

«Адвокат дьявола» - определённо один из лучших фильмов. Нет, не в топ-3 или 5, но назвать пусть 15, которые точно нравятся больше, я не смогу. Сам персонаж Аль Пачино, его актерская игра и невероятное попадание в актера дубляжа подарили несколько шикарных сцен, ради которых просто стоит смотреть и пересматривать.

«Адвокат дьявола» - невероятный фильм. И я надеюсь, что большинство его смотрели. Но мало кто знает, что это экранизация романа Эндрю Найдермана. Ну как экранизация. Скорее «по мотивам». Книга, по сути, вообще о другом. Фильм мне нравится больше – и это редкий случай, обычно я из тех, кто «книга лучше». Но она определенно стоит того, чтобы её прочитать. Тем более, что она небольшая, за вечер можно управиться.

P.S. Если что, фото взято из открытых источников

#медведьрекомендует #почитать #посмотреть

Парное программирование как мощнейший инструмент обучения.

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

Притча.

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

Если разработчик в какой-то момент своей карьеры оказывается в точке, определяемой как совпадение его навыков и черт характера, а также навыками коллег (точнее их отсутствием), он решает: Надо кого-нибудь обучить. Желательно самого слабого, чтобы он потом не смог конкурировать.

Отступление

правда в последнее время «обучить джуна» все чаще заменяется на «обучить нейронку»

Новоявленному наставнику тут же спешат на помощь всякие методики, ИПРы, стажировки и прочая. Но парное программирование для меня является лучшим вариантом. Разумеется, оно не может быть единственным. Просто практический эффект от сессии ПП достигается быстрее, чем от чего-либо другого. Ввиду отсутствия классических ролей «ведущего» и «штурмана» (логика или википедия, при отсутствии первого, Вам в помощь), скорее можно назвать лайв-кодингом. Но я буду называть как хочу. Беее😜

Итак, почему парное программирование так хорошо ложится и в обучение, и в рабочий процесс в целом
👉Не отменяет других форм обучения (от ИПР до «блять, тебя что, в гугле забанили?»)
👉Отлично вписывается в цепочку жизни задачи «поставлена – вызвала проблемы – позвали эксперта – решили»

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

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

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

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

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

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

#медведьразмышляет #обучение

Как не стать legacy?

Спойлер никак

Аксиома

Любой код, написанный любым разработчиком, станет чьим-то legacy

Поправка

При условии, что доживет до стадии рабочей системы

Дополнение

Иногда реализованные Вами решения станут Вашим legacy

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

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

Как не породить жуткое legacy?

Лежит в той же плоскости, что и

Как сделать нормальную систему?

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

Ну а теперь давайте формализуем требования
👉Документация. В любом виде: БТ, ФТ, ТЗ, переписки, записи встреч, база знаний, комментарии в коде, задачи в джире, планы в конфлюенс – всё, что спустя время поможет ответить на вопросы: кто, когда и нахуя затребовал/сделал очередную фичу
👉Соглашения при разработке. Главное не доводите до абсурда и не регламентируйте количество пробелов в комментариях между номером задачи и тем, кто ее сделал
👉Рефакторинг и код-ревью. Регулярные. Чем чаще, тем лучше. Помогает отследить неоптимальные во всех смыслах решения и поддерживать целостность.
👉Грамотные решения при проектировании и разработке. Выделять что-то отдельное смысла нет, а говорить обо всем – начинать отдельную серию постов. Все то, что люди понимают, говоря слова «чистый код» и «чистая архитектура»
👉Тестирование. В идеале – автоматическое. Как минимум – ответственное.
👉Возводите критические точки в абсолют. Везде, где это возможно. Если по ТЗ надо проверить 5 независимых свойств, прикиньте, как выбранное Вами решение будет выглядеть, если свойств станет 50. А как, если часть из свойств будет зависеть от других свойств? Вместо «ну не будет же пользователь творить лютую нелогичную херню» считайте, что он начнет делать её сразу, как получит доступ к фиче. И так далее.

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

Еще есть один пункт, который точно делать не стоит: замыкать какую-то часть решения на одного специально обученного человека. В таком случае, особенно при невыполнении некоторых пунктов из списка «стоит», есть риск получить на самом деле незаменимого человека.

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

#медведьразмышляет #legacy