Антон Носков | Разработка для е-ком

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

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

Надо научиться увольнятьУ каждого руководителя неизбежно наступает момент когда надо уволить сотрудника который «не тянет».Как и о много другом, тут легко только рассуждать. И нихуя не просто делать.От банального отсутствия полномочий у руководителя, те же тимлиды не всегда наделены правами увольнять разработчиков.До страхов «а кто будет делать вместо него, нужно заменять плавно, а бюджета на найм еще одного — нет», «Как же я его уволю, он ведь как родной, у него дети» и тд.И вот это пиздец, тянуть до последнего, когда внутри уже решил, что у сотрудника нет будущего в компании. Кому от этого будет лучше? Команду разработки, где все молодые и амбициозные однозначно надо строить по принципу увольнения. Не бояться расстаться с сотрудником, если он не подходит или перестал подходить — такое ведь тоже бывает, вы все выросли, задачи усложнились, а кто-то остался там же где был год-два назад. Увы. Ловушка в которую я попадал не раз — это тянуть чуваков и чувих, которые серединка на половинку: ответственный, всегда на связи, че то делает. Но при близком рассмотрении — это не тот уровень который тебе нужен. Ты день за днем закрываешь глаза на проблему, лишь бы не принимать сложное решение, не разговаривать неприятные разговоры. Но самое главное, что ресурс на обслуживание сотрудника в компании должен снижаться после онбординга в проекты и процессы. А именно такие ребята, всегда будут его тратить больше нормы — ресурсы тимлида, тестировщика и прочих коллег. Чтобы добиваться нормального качества от них нужно больше менеджмента, больше итераций код-ревью, больше тестирования. Зачем оно тебе? Ps нет, ты никому не искалечишь судьбу, если человек умный — он найдет свое место, а если дурак — его уже ждёт оффер х2Pss само собой надо соблюдать трудовой кодекс. Тут главное принять решение, остальное формальности

Дать разработчику самому «добежать последнюю милю»Все руководители так или иначе решают вопрос самостоятельности сотрудников. Некоторые с этим справляются хорошо и спокойно ходят в отпуск, на больничный и даже на дачу без ноутбука ездят (это экстрим, честно).Некоторые становятся тимлидами / менеджерами / СТО единорогами, без которых ничего не работает и не решается — то есть справляются так себе. Зато чсв чешут. Но в туалет отойти не могут, чтобы что-то не разъебалось в их отсутствие. Честно говоря, я точно не в первой категории, но и из всех сил стараюсь не оказаться во второй.И вот один из важных принципов выращивания вдумчивых, самостоятельных технарей (и не только их): когда он или она приходят к тебе с вопросом по задаче — не приносить решение, а приносить мысль. Чтобы человек пошел, подумал, вернулся с кривым решением, ты его еще раз подтолкнул в нужном направлении и вот на второй-третьей-четвертой попытке будет то, что сгодится. Зато он сам понял как и зачем. А не получил всё на блюде) И это пипец как сложно, сдержаться от того, чтобы сразу выпалить решение — это же быстрее и сделано будет хорошо, и вообще одни плюсы. Кроме только того, что в следующий раз ты снова получишь подобный вопрос. А когда у тебя в подчинении не 1,2,5 а сильно больше людей — финита ля комедия. Будешь всегда на связи — спать с телефоном, есть с телефоном, мыться с телефоном.. дальше сами додумайте. Короче, растите своих крепких мидлов, на которых держится мир и не будете загнанной лошадью.

Кто такой Антон Носков?А нет такого чувства, что описывать самого себя это странно? Лучше бы пользы принес или шутку подкинул.. Особенно, если собираешься писать в канал «налегке», а потом три дня выдавливаешь новое описание себя.Поэтому очень кратко. В прошлом году я был тим-лидом разработки с амбициями СТО. В этом году я им и остался. Мне есть чему учиться на текущей позиции, так что ок.Писать буду о том, что вижу каждый день — про жизнь тим-лидскую, про процессы в небольшой команде разработки, где каждый воин, каждый машина (которая иногда ломается). Про код иногда. Поныть никогда — тоже иногда. Развернутое описание, что мы за команда и чем вообще занимаемся — есть, и оно пока норм. Этот пост нужен только лишь для выравнивания контекста. Го к шуткам. Заходит как-то тестировщик в бар..

Бизнес: нам нужны крутые разработчики, чтобы пилить нагруженные системы и интеграцииТакже бизнес: мозно мне курсор в виде сердечка? ❤️ Разработчики: :-|

В последний рабочий день провели общий созвон с командой, подвели итоги, рассказали о самых интересных задачах в этом году.2024 год можно назвать для нас во многом определяющим:- нашли свою специализацию в развитии еком-систем;- сфокусировались на стэке php, битрикс;- собрали сильную команду разработчиков с фокусом на екоме;- поняли, что такое долгие проекты и как работать с клиентом годами;- построили понятные внутренние процессы;- начали строить отдел тестирования.Сила команды определяет всё! Именно в команде аккумулируется опыт, экспертиза, ответственность, качество решений.В новом году мы продолжим усиливать команду разработки, чтобы просто разработчик стал еком-разработчиком.Усилим наш маркетинг и пиар, будем доносить нашу экспертизу до нужных нам компаний.С наступающим, коллеги! 🎄🎄🎄

Маленький кусочек пятничной рефлексии (про трудности письма)Тем кто читал Мураками «О чем я говорю, когда говорю о беге» знакомы его сравнения написания текста с желчью, которая сжигает изнутри. Он пишет, что если бы не бегал, то написание книг убило бы его (а ежедневные пробежки позволяют выплескивать весь этот негатив. И пробежки у него серьезные — по 10км/ день, 300км/ месяц 😱).Не уверен, что имею право на подобные сравнения со своими «записками», но.. что-то в этом есть. Многократные переписывания, подбор выражений и форм, усилия мысли. Все это как будто жрет, если уж не меня, то время точно.Пишешь, потом переписываешь, потом думаешь, что налил воды и надо оставить только важное — переписываешь. Потом думаешь «ну сухо же!» и еще рерайт. При этом оно затягивает и хочется довести до точки, если не получается — можно и психануть.В итоге столько усилий, импульсивности и прочей суеты вокруг постика. Потом легкий мандраж, чтобы «отпустить» пост в канал.И в конце спрашиваешь себя, а не слишком ли много я думаю об этом?) При том что в большинстве случаев получается заурядно, завладеть чьим-то вниманием целое искусство, зачастую даже негатива никто не напишет.Проще говоря, вымученные, натужные тексты никому не нужны.Есть желание дать себе больше вольности и писать свободнее. Посмотрим, что из этого выйдет.

Приложил руку к краткой статье о том, как мы принимаем проект на поддержку. Наша поддержка – это про долгосрочное развитие проекта. Формирование команды, встраивание в процессы заказчика, квартальные планы. Но прежде чем это всё случится, надо принять проект и не облажаться ввязавшись в большой геморрой (который подается под видом интересного проекта, откуда по чистой случайности сбежал прошлый подрядчик).В статье простой список шагов, которые помогают нам въехать в проект и понять все ли с ним ок. А также подготовить инфраструктуру для старта работ. Вспоминаются времена лет эдак 10 назад, когда всё, что мог передать нам потенциальный заказчик по сайту – это доступ к хостингу (легко до подписания договора, а про NDA вообще никто не знал) и список задач в виде “Не работает интеграция с 1С” – бросает в холодный пот. Современный е-ком сильно сложнее. И чтобы принять проект – нужно попотеть)Читать на VC >>

Time & Material, квартальное планирование, долгие проекты, фокус на одном направлении - всё, что обеспечивает стабильность в работе.Рассказали в статье как отказались от проектной работы в пользу долгих проектов и научились встраиваться в процессы клиентаСтатья на VC>>