Преждевременная оптимизация

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

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

Вот моменты, которых советую придерживаться:
1) Постарайтесь посмотреть на готовые решения. Учитывая, что вы еще не профи, врядли вы делаете что-то принципиально новое, посмотрите готовые аналоги и решения:
- Причем как в глобальном плане, обратите внимание по какой логике работают похожие готовые сервисы, это поможет. Например если вы делаете интернет-магазин с множеством настраиваемых свойств товаров — посмотрите как управление ими устроено в готовых cms. Референсы даже с точки зрения пользователя — многое могут сказать про необходимую архитектуру.
- Так и в мелочах и отдельных фичах, посмотрите нет ли для вашей задачи готовой библиотеки, только обратите внимание на ее популярность и обновляемость. Если скачиваний много, проблемы регулярно закрываются, и пакет обновляется - скорее всего в нем продумано намного больше, чем вы сможете сделать с первого раза, а в мелочах можно допилить по надобности. Например если перед вами стоит задача настройки гибкой системы прав доступа пользователей, или даже добавление банальной механики сторис в приложение — это явно похоже на типичные задачи, к которым вероятно есть популярное готовое решение, поищите.

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

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

4) Дорогу осилит идущий, не пугайтесь незнакомого и объемного — пошагово и планомерно выполняйте подзадачи, выбирая в первую очередь простые и понятные решения. Документируйте свой код и учитесь формулировать отчеты о проблемах и обоснования выбранных решений — правильно заданный вопрос, уже половина ответа. А изящные решения, лучшие практики и идеальная архитектура придут с опытом, не волнуйтесь

Сапожник без сапог

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

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

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

С чем работаем еженедельно

Каждую неделю студия работает над приличным числом параллельных проектов, на прошлой 15 например. Объем и сложность со временем растут, держать все под контролем нелегко, но к счастью уже выстроилась система как делать это эффективно. Но об организации и процессы в другой раз. А сейчас о том, что обилие разноплановых проектов, дает кучу полезного опыта, баек и ситуаций, однако оформлять это дело в полноценные кейсы получается не так часто, как хотелось бы. Так что попробую формат попроще: еженедельный микрокейс из нашей постоянной текущей работы. Это будут технические детали, байки об управлении, а может какая-нибудь реализованная мелочь, посмотрим как получится, начнем

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

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

Очередной регулярный минирассказ с прошлой недели

Наконец добрался отписать что-то. Итак, история о недоделанных проектах: обратился клиент, с уже написанным проектом, где "почти все готово" и осталось добить пару моментов до запуска, с чем и надо собственно помочь. С прошлой командой доделать не получилось, какие-то проблемы, а запускаться нужно. Ситуация не редкая, не в первый раз сталкиваемся, для дооценки задач нужно развернуть то, что уже есть и проглядеть что и как работает. Начинаем развертку и становится ясно — гладко не пройдет, без тестовых данных сыплются ошибки, исправляешь одно — появляется следующее. Дампов и развернутого сервиса при этом нету, непонятно проблемы в коде или что-то исправляется инфраструктурой. Все конечно решаемо, но давать оценки в такой ситуации — не получится. Потому даже на развертку того, что есть приходится согласовывать рабочие часы, разворачивать проект на сервере клиента, и решать поочередно попадающиеся ошибки, чтоб можно было начать совместное тестирование с клиентом. Оказывается, что код после каких-то последних изменений не тестировался, уверенности в том насколько внутри еще неожиданностей — нет. При том визуально код неплох, сделано явно много, и не зная всех деталей разработки, изменений ТЗ, качества требований и деталей договоренностей говорить, что можно было сделать изначально лучше — я бы не стал. Скорее всего многие проблемы — следствие причин которые с наскоку не видны. Но и сервис в по сути нерабочем состоянии: кроме тех вещей о которых клиент был в курсе, выплывают ошибки по другим частям приложения, не работает то, что раньше вроде как работало, а какие то вещи просто не проверялись. Время и ресурсы на починку и доделку — труднооценимы.

Выходит ситуация: все, что мы можем — это поэтапная доделка сервиса по Т&M. То есть делаем док под список доделок, вносим туда, что уже найдено, и что находится по ходу продолжения тестирования и доработок. Прикидочно оцениваем сколько будет уходить на что, без гарантий, а только для понимания порядка цифр для возможности расставить приоритеты. Согласуем пачки работ например на 1-2 недели, оперативно держим в курсе статусов, сообщаем если где-то ориентиры оказываются неверны, предлагая варианты упрощения или замены. При том оплату получаем за фактические часы. Удобно, так как оценить проект с гарантией на полпути — было бы слишком рискованно, а клиент получает возможность хотя бы регулировать бюджет, получая прозрачные статусы и отчеты и в реальном времени принимая решения о том отказываться ли от каких-то частей проекта, или увеличивать бюджет доделки. Но и минусы для клиента тут очевидны: точный бюджет не получаешь, уверенности, что в имеющиеся деньги получишь то что представлял — тоже. Гарантий на это нет, а скорее всего (проект то не доделан не просто так) проблемы с доверием и гарантиями у клиента уже появились. И конечно возникает вопрос: так может выкинем все что есть, оценим с нуля и сделаем сразу красиво?

Мое мнение тут: если проект не был доведен до реального запуска, а с кодом можно хоть как-то работать — нужно добивать до запуска. Да уже с потерями, да всякое бывает, но это будет:
1) Дешевле. Возможно будут проблемы с техдолгом в дальнейшем — но решать их, когда гипотеза протестирована — намного лучше
2) Надежнее. Если проект как-то демонстрировался, и в нем с багами, но работало, и нуждается только в исправлениях хотя бы половина того, что вы хотели — доделка будет оптимальна. Далеко не факт, что при переделке до реального запуска анализ проекта с нуля станет лучше, чем первая попытка. Исправляя какие то ошибки первой версии можно наделать других, и что будет хуже без реального опыта — не понятно. Доделывать проекты до конца сложно, и раз уж да с проблемами, но к этой вехе уже подошли — лучше брать силы в кулак и добивать. Шанс на успех будет выше, чем пытаться сделать идеально с нуля. Другое дело переделки уже после запуска и работы— тут да, обсуждаемо
3) Быстрее. Даже обсуждать не стоит, да и проблемы с изначальной разработкой взялись не на пустом месте, то что в нее было вложено не стоит недооценивать, велик шанс так же ошибиться.

На прошлой неделе выкатили одну занятную штуку для постоянного клиента: учебную версию его же платформы. Идея проста, и я уверен, что это полезно и другим обладателям не коробочных разработок. Итак проблема: внутренняя разработка, чем бы это ни было, хоть erp, хоть crm, хоть как в нашем случае платформа регулирующая все от клиентских чатов до рейтинга сотрудников, в силу индивидуальности, имеет один минус — работе в ней новым сотрудникам придется обучаться с нуля. Документация пользователя для таких разработок не всегда полна, да и не решает вопрос полностью, а новые доработки в таком софте вносятся постоянно, так как живому бизнесу регулярно нужны изменения. Чаще всего сотрудников обучают "на пальцах": опытный работник показывает куда тыкать в боевых условиях, новичок запоминает. Эффективность — такая себе, редкие кейсы так сразу не показать, проверку обучения провести затруднительно, сотрудник тренируется на реальных данных — а это не безопасно.

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

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

Готовимся к нагрузке

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

До этого у нас уже были проблемы в пиковые моменты, так что на этот раз подготовившись уже с опытом, получилось успешно выдержать нагрузки в разы превосходящие прошлые. Базовые моменты которые можно сделать всем если вдруг у вас ожидается ажиотаж:
✅ Настройте мониторинги и уведомления, о проблемах и падениях всегда лучше узнавать автоматически.
✅ Проверьте явные моменты: долгие запросы в бд, наличие необходимых индексов, нет ли запросов в циклах, и нельзя ли где то запрашивать меньше данных. Первое узкое место это всегда база данных, так что сосредоточьтесь на проверке запросов к ней.
✅ Проверьте настройки инфраструктуры: на любом ее уровне там могут быть моменты требующие внимания, не используются ли случайно дефолтные настройки mysql у вас на проде? а нормальные ли таймауты в livenessProbe сервисов в кубике? вопросов тут много, потому оптимизация под нагрузки всегда сложный момент, но пробежавшись и улучшив хотя бы основные моменты вы точно сделаете лучше.
✅ Настройте кэширование информации со сложных запросов в бд, даже кэш на 1 минуту, в случае большой нагрузки даст громадный прирост к отказоустойчивости. Увеличьте время жизни кэша везде где это возможно, чем реже запрашивается информация из бд тем лучше.
✅ При возможности можно рассмотреть шардирование бд или распределение запросов чтения по репликам, хоть и врядли это уместно для мелких проектов.
✅ Не забывайте о фронтенде, убедитесь что он развернут по всем рекомендацим для продакшена, нет никаких ограничивающих факторов, например в случае фронтенда c ssr на ноде, что он поднят в несколько процессов через кубер/pm2.
✅ Если есть возможность проведите стресс-тесты (gatling в помощь), чтобы выявить и успеть исправить явные проблемы, чаще всего если нет проблем с обращениями к бд могут быть проблемы в настройке инфраструктуры, выявить и исправить их без тестов - проблематично.
✅ При возможности заранее увеличьте ресурсы, увеличивать ресурсы уже под нагрузкой будет очень неуместно, лучше выделить время в нерабочие часы. Даже автомасштабирование не работает мгновенно и можно накопить очередь запросов, так что для ожидаемых пиков лучше сделать это заранее.
✅ Подготовьте план на случай плохого сценария. В лучшем случае это автомасштабирование и распределение нагрузки лоад балансером, но для мелких проектов чаще всего настроить облачные ресурсы и само приложение готовым к этому бывает невозможно. Но даже для сервисов на классических простеньких серверах, можно придумать "план б" с отключением неприоритетных модулей, включением статических заглушек, и прочих возможностей.
✅ Ну и не совсем к вопросу нагрузок, но всегда уместно, у вас же настроены бэкапы?)

Безопасность и взломы

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

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

Как? Взлом это автоматический процесс, чаще всего работают атаки через набор уязвимых мест:
- Части кода популярных cms и систем. Сайты неоправданно писать с нуля, большинство из них написано на готовых cms состоящих из большого числа готовых модулей. К тому же всегда дополнительно устанавливаются разные готовые пакеты от сторонних разработчиков. Где-нибудь да проскочит уязвимость. А сайтов с этой уязвимостью выйдет сразу много.
- Банальный подбор паролей на все начиная с админки, заканчивая ssh доступом к серверу. Если глянуть в логи доступа сервера, то даже у самого мелкого сайта увидим и попытки ботов залогиниться в админку и кучу запросов напрямую к самому ssh. Так что использование небезопасных паролей чревато даже если кажется, что атаковать вас никому не надо, ботам все сгодится
- Человеческий фактор, фишинг, социнженерия. К этому методу относится все рассчитаное на неосторожность людей. От автоматически генерируемых сайтов похожих на вашу админку и рассылок с ними на почту, до утечек через старых сотрудников (привет, Петь, слушай у нас затерялись доступы, а Федору Иванычу нужно прайс поменять, скинь пожалуйста что у тебя оставалось). Методы и так всегда были популярны, а сейчас с развитием ии еще больше масштабируемы и автоматизируемы.

Можно ли защититься? Полностью — нет. Направлений атак слишком много, аудит безопасности всех модулей (сторонних и модулей ядра) невозможен, да и все равно остаются методы от которых технически не защититься. Но значительно уменьшить шансы на взлом и уменьшить возможные последствия — вполне реально и нужно делать.
- Регулярно обновляться. Версии основной cms, всех модулей и пакетов, софта на сервере. Да это тратит время и деньги и иногда требует адаптации, но точно увеличит стабильность
- Никаких легких или одинаковых паролей, в идеале еще и регулярно их менять раз в какой то период.
- Не открываем наружу ничего лишнего, ставим везде базовые инструменты защиты от брутфорса, закрываем стандартные порты
- Проводим обучения людей, следим за сменой доступов и минимизацией количества носителей критической инфы
- Ну и конечно настраиваем бэкапы во внешнем хранилище, полная защита невозможна, а потому пусть всегда будет план Б.

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

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

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

Короче подойдет всем, от только интересующихся, до уже практикующих. Но нужно понять количество и уровень желающих, чтоб разделить по группам удобного размера и все организовать. Так что, если вам было бы интересно — плюсаните в комменты, свяжусь уточню по уровню и интересующим вопросам и все организуем. Участие бесплатное, формат (оффлайн/онлайн) определится позже

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

Айти это сфера где "хочешь жить — умей вертеться", навыки в адаптации и обучении здесь ценятся всегда и всеми выше всего. Ситуации, технологии и условия меняются постоянно, за всем нужно успевать и решать проблемы. Потому многие вещи необходимость в которых в других сферах выясняется лишь при проблемах, у нас уже давно — норма жизни. Те же самые процессы обучения, внутренних наставничеств, передачи знаний. Для любой мало мальски окрепшей команды в айти известно понятие bus factor и понятно, что нужны процессы при которых сотрудника на проекте можно подменить, переключить, нужны процессы ввода в проекты новых людей, процессы их подготовки.

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

Синдром менеджера

Узнал тут на таблетках новопассита, что оказывается есть вполне себе сформулированный "синдром менеджера", который отражает почему управленческие должности это не так уж и весело, как многим кажется изначально. Вспомнил десятки своих собеседований на ПМов с ребятами думающими, что в айти сильно проще зайти со стороны управления или что всё, что нужно руководителю это "уметь общаться с людьми", чтобы это там ни значило. Ну кодеры ведь стопудов не умеют, мычат что-то на своем и от людей шугаются, два слова связать не могут ага-ага. Толи дело общительная девочка, комсомолка, спортсменка и просто милое создание, ведь достаточно улыбнуться и попросить — клиенты простят все проебы, а кодеры начнут работать каждый за троих, причем за бесплатно (мальчиков так считающих кстати не сильно меньше). Реальность правда оказывается чуть интереснее, отвечать за чужой труд сложнее, чем за свой, фокус нужно держать на нескольких вещах одновременно, контролировать много, быстро понимать и разбирать временами сложные вещи, для того чтоб правильно интерпретировать информацию и принимать решения. Оказывается ни одно из управленческих решений не является панацеей, и к каждой ситуации нужно анализировать кучу переменных, для выбора что делать. И при этом ничего не гарантирует, что даже если ты все сделаешь "правильно" то все будет хорошо — нет, не факт, мы лишь увеличиваем вероятности успеха или провала, но я видел ситуации когда человек делал все, что можно правильно и в итоге все равно был провал, как видел и случаи когда все было сделано хуже некуда — но проект запускался вопреки. Да это исключения, и навыки хорошего менеджера дадут всегда выигрывать на дистанции, но в моменте все это может знатно давить на кукуху. 

И вот самый главный навык менеджера это стойко держать это давление. Факторов много, но новички точно будут получать море критики со всех сторон, и естественным желанием будет защищаться и придумывать объяснения "почему не получилось". Это естественная реакция, но неверная, ведь главное правило управленца — всегда можно лучше. И в этом парадокс, так как вечный спрос с себя тоже давит. Хорошему менеджеру трудно меньше спрашивать с себя, а потому уйти в выгорание — вопрос времени. Вот так, если ты менеджер ты всё равно выгоришь, либо раньше не готовый к прямому давлению, либо позже не успевая восстанавливать ресурсы, но выгоришь 100%. Избежать этого получится разве что если от тебя на самом деле не так уж много зависит, и твоя роль действительно улыбаться на митингах и спрашивать людей как у них дела, и то не уверен. Так что действительно неплохой термин придумали, одобряю. Другое дело, что подобное это стадия роста, и да рост это больно, но необходимо. Так что, если у вас подобные трудности и вам станет легче — вы не одни, у всех так, не волнуйтесь все пройдет

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

Дел много, поэтому усиливаем команду и ищем новые руки и головы https://studio-alt.ru/blog/myi-snova-ishhem-razrabotchikov пишите.

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

Хорошие новости в том, что в принципе в этом нет ничего нового: умение видеть задачи в целом, системно разбираться в незнакомом, уметь выражать мысли, коммуницировать, ставить четкие метрики результатов и видеть те места на которые стоит обращать внимание, а где в целом вопрос стоит лишь в механических действиях — ценились абсолютно всегда. Разработчики с этими качествами ценились всегда, и спрос на них никуда не денется — будут нарасхват. А вот "механические" навыки потихоньку будут падать в спросе. Специализации тоже станет поменьше, много ли смысла в разрабе с глубокой привязкой к одной технологии например, если во всех llm эти знания вшиты ничуть не хуже, а хороший архитектор сможет с их помощью решать задачи без привязки к конкретному фреймворку? Конечно такое будущее еще не наступило, но тенденция уже заметна, требования к джунам — везде повышаются, стажеры "набиратели кода" все меньше кому нужны, увеличиваются требования к умениям аналитики и пониманию сути бизнес-задач для рядовых исполнителей, и эти процессы будут усиливаться. Будет интересно посмотреть к чему все придет, и как именно изменятся процессы разработки, но то, что новичкам нужно адаптироваться уже сейчас это точно. Так что тренируйте мозги и гибкое мышление, пригодится:)

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

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

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

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


В целом опыт определенно новый и интересный, и я надеюсь, что будет полезный. Выпуски выходят по субботам, первый был, ссылка в вк https://vk.com/wall13699865_286

Всем привет, дата встречи для кодеров определена

3 июня в 18:00. Спасская, 15. Вход в музей шоколада «Криолло»

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

Темы:
* «Как не совершить базовые ошибки в разработке веб-приложений: немного о безопасности и о чем стоит подумать если вы начинающий разработчик»
* «CI/CD что это и зачем нужно»
* «Проектирование и разработка приложений. Как подходить к разбору сложных задач»

Зарегистрируйтесь пожалуйста, чтобы мы прикидывали финальное число людей https://forms.gle/sPHQHZSAVGJeNdhX7

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

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

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

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

Для эффективной коммуникации нужно много навыков, начнем с начала. Для того чтоб в итоге какие-то задачи были выполнены, очевидно, что нам придется эти задачи ставить и поручать людям. И первое, что необходимо для того, чтоб задача была сделана — она должна быть людям хотя бы понятна, и здесь уже есть трудности. Оказывается одни и те же слова люди понимают по разному, в зависимости от контекста, бэкграунда, настроения и черт еще знает чего. Наши слова всегда понятны нам, но остальные могут в них видеть абсолютно другое — причем у неподготовленных людей такое по началу вызывает дикое раздражение, ведь мы то прекрасно понимаем, что имели в виду и понять это по другому мог только дурак, еще и не переспросил же. Однако при этом сами также часто неправильно понимаем других, но в этом случае это конечно же потому, что это они все плохо сформулировали, ага. Посмотрите крутое старое видео https://youtu.be/w7F80U-pPVk?si=34JJCAXw4VgMWz6E отличная демонстрация того, о чем я говорю. Классное упражнение, понаблюдайте за детьми в том числе в сравнении друг с другом. Что можно для начала коротко извлечь отсюда:
1) Точность формулировок и передача полного контекста по задаче сильно улучшает результаты.
2) Нас все равно могут не понять, и в этом нет ничего страшного, нужно контролировать выполнение, и уточнять моменты по опыту. Полезна и аналогичная мысль, что и мы, видимо, настолько же часто неверно понимаем других людей, и постараться уменьшить такие случаи задавая больше вопросов, и озвучивая свое понимание, чтоб нас могли поправить заранее. 
3) Исправления и неудачи это не катастрофа, а эмоции и раздражение наш враг. Уход в раздражение замедляет решение проблем, и ухудшает результаты исправлений сделанных под ним. Учимся стрессоустойчивости и принятию.

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

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

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

Исполнителю хочется конечно взять и выдать этот идеальный результат. Но иногда это невозможно. И нужно что-то делать в неидеальной ситуации. Хорошие новости в том, что большинство людей с опытом понимают, что без проблем — не бывает. И то, как вы строите взаимодействие при проблемах даст больше лояльности, ведь проблемы все равно будут, а если человек в них действует прозрачно и понятно, с ним можно работать и дальше. Итак, что же делать
1) Даже если кажется, что уже поздно сообщать о проблемах — это не так. В кейсе выше исполнителю это казалось всю дорогу, и каждый раз он жалел, что не сообщил в прошлый
2) Оправдываться не надо, в конфликте попытка защиты будет его только разжигать, проблемы и проебы надо признать. Признание фактов - гасит раздражение, и клиент быстрее начнет смотреть на ситуацию в практическом ключе. Да и честный рассказ о проблемах добавит клиенту понимания ситуации, а это ставит клиента на нашу сторону, и убирает у него мысли о том, что его злонамеренно опрокидывают.
3) Разбирать прошлое в стиле "а вот если бы" нет смысла, лучше рассмотреть какие варианты есть здесь и сейчас.
4) Не надо кормить надежды об "идеальном" варианте — если не прокатит, даже хороший результат будет казаться проигрышем. Идеального варианта может не быть и важно дать клиенту варианты не желаемые, а те что есть на самом деле.
5) Будет отлично добавить перечисление мер для улучшения ситуации в будущем.

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

Завтра, 18го сентября в 18.00 по мск Павел Ананьин, один из наших тимлидов проводит онлайн митап. Расскажет немного о go, проблемах, что он решает и опыте применения в проекте написанном на другой технологии.
Приходите, обсудим, будет интересно, ссылку скину сюда же

начинаем через пол часа