Principal Applications Architect в Cleverbridge
  • 🔥Як тимліду рухати вперед командні задачі?

    Особисті цілі виявляються і підтримуються піпл менеджерами, зараз я таким не є, але коли був — то «все як у всіх», тобто регулярні 1-1, прозора комунікація, відповідність компенсації та її зростання до зростання співробітника. Бізнес цілі — трохи по-іншому, тут є рівні. Спочатку С-левел визначає стратегію компанію у принципі і трохи деталізує її на кілька років, здебільшого по бізнес метрикам. Потім CTO / CPO / VPoE працюють на тим, як реалізувати ці плани доступними ресурсами (груба кажучи дуже високорівнева пріоритезація продуктів і фічей). Це вже планування десь в горизонті півроку. Потім є процес крос-командного планування на квартал де вже конкретні (втім все ще великі) фічі оцінюються і планується делівері окремих компонентів різними командами. Потім це ще деталізується і робиться чекпоінт вже всередині команд кожні 6 тижнів. Ну і кожен спрінт є ревʼю мітинг де трекається прогрес зовні, і ретро для того самого всередині.

    Чим компанія більша, тим ланцюг довший, і тим довший зворотній звʼязок. Тому ключовий момент — зменшити час передачі даних між крайніми ланками, і ваша відповідальність як ліда це побудувати процес «вниз по ланках» так, щоб до вас у випадку чого сигнал прийшов asap, і передати цей сигнал по ланці вгору (куди має сенс) так само швидко. Це приклад доволі вертикальної організації, в горизонтальних звісно інакше — тут вже не підкажу зі свого досвіду бо не маю такого.

  • 🔥Як тимліду рухати вперед командні задачі?

    Цілі можуть бути внутрішні (що людина хоче сама) і зовнішні (що від людини хочуть інші). Внутрішні цілі ставити не треба, їх в найкращому випадку треба просто виявляти (і то якщо є така задача як піпл менеджера). Зовнішні цілі, підозрюю, вам і вашим командам ставить бізнес. Тому сфокусуюсь на них.

    1. Зовнішні цілі рідко формуються в дев тімах, вони туди приходять згори по продакт вертикалі. Тож раджу фокусуватись на цьому. Якщо звідти не приходять задачі чи їх дуже мало — це вже інша справа, але таке рідко буває, зазвичай навпаки хєр пріоритети розставиш (і тут ви як лід як раз і маєте сяяти).

    2. Знову ж таки, цілі всередині команди зазвичай мають слугувати як продовження цілей бізнесу / продакту (окрім як ви маленький стартап і дев тіма то і є вся компанія). Тому головне, на мою думку — прозоро комунікувати стратегічні (та й інші) задачі зовні команди і на основі їх формувати цілі команди, аля «як ми команда Х можемо допомогти компанії досягнути цілі Y». Люди, звісно, завжди більше люблять робити те що їм цікаво, і якщо це радикально протилежне цілям компанії — діла не буде. Але то вже проблема хайрінгу чи resource allocation, яку ви маєте просто адресувати потрібним людям.

    3. Мотивація у кожної людини внутрішня, я особисто не вірю в те що людину можна «замотивувати» зовні. У більшості мотивація проста — робити те що подобається і отримувати за це найбільші можливі гроші. От наскільки близькі до цього умови ви зможете створити для своїх співробітників, настільки вони і будуть вмотивовані :) Також можна пробувати матчити внутрішні цілі конкретної людини з її задачами, але це вже якщо є час та бажання.

    Моя головна порада — сприймайте свою команду як дорослих адекватних людей, які розуміють що таке бізнес і як він працює. І памʼятайте що кінцева мета будь-якого бізнесу — це прибуток, тож всі цілі мають бути так чи інакше направлені на це, просто ви як інженер маєте іншу перспективу ніж, наприклад, маркетолог (на вас покладена задача тримати продукт scalable, maintainable, secure, performant, functionally adequate і цілі мають бути відповідні).

    З іншої сторони, якщо проблеми команди не конвертуються в цілі які їх вирішують, команди може не стати. Тож також ваша задача або вчасно для цих «командних» цілей вибити ресурси, або як мінімум прозоро повідомити про це вже ваших менеджерів які приймуть рішення.

  • Как подружить разработчика и менеджера

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

  • Как подружить разработчика и менеджера

    К сожалению, не во все команды можно нанять только сеньоров. Более того, не все сеньоров действительно зрелы и развиты именно в этом контексте — понять продукт, задачу и решить её максимально эффективно. Все мы люди :)

  • Как подружить разработчика и менеджера

    Ок, берет напрямую. Проект растёт. Промотаем чуть времени — проекту несколько лет, он выстрелил. Для его успешного развития уже недостаточно просто «чуйки» заказчика или вашей. Нужны исследования рынка, работа с фокус группами, приоритезация, беклог на несколько команд, стратегия, OKR, KPI...

    Если это все продолжает делать заказчик — тогда он менеджер. Если вы — то вы.

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

  • Как подружить разработчика и менеджера

    А кто этому фрилансеру задачи даёт?)

  • Как подружить разработчика и менеджера

    Я же не писал что отвечает за это :) Но для него это важно. Я понял суть ваших слов, и согласен с ними — наверное, в статье выбрал неудачную формулировку.

  • Как подружить разработчика и менеджера

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

    А насчет перфекционизма — бывают и менеджеры-перфекционисты :)

  • Как подружить разработчика и менеджера

    «Качественно и надежно» — сложное понятие, ведь оно зависит от конкретной ситуации.

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

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

    Підтримав: Євген Козлов
  • Как подружить разработчика и менеджера

    Хороший summary :)

  • Как подружить разработчика и менеджера

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

  • Как измерить программиста

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

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

  • Не разработчик и не менеджер. Что означает быть лидом

    Скажу за себя — самореализация и деньги. Думаю, что у других людей они могут отличаться.

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

  • Не разработчик и не менеджер. Что означает быть лидом

    Спасибо!

    На самом деле, наша команда проходила долгий путь от forming до performing, спотыкаясь, но не сдаваясь :) Было и становление процесса как такового (с 0 до 2-3 уровня process maturity model), и формирование команды, и осмысление культуры — как работы, так и коммуникаций.

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

  • Не разработчик и не менеджер. Что означает быть лидом

    Плюс-минус :) Прораб он и в айти прораб.

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

  • Не разработчик и не менеджер. Что означает быть лидом

    Стесняться? Вы ошибаетесь.

    Насчет ВУЗа — я просто написал то, что у меня в дипломе.

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

    Надеюсь, во время моего следующего визита домой найду время проведать и сказать им это лично :)

    Підтримали: Mykola Savoniuk, Artem Frolov
  • Не разработчик и не менеджер. Что означает быть лидом

    Спасибо! Очень приятно читать такие комментарии :)

  • Не разработчик и не менеджер. Что означает быть лидом

    Ви частково праві. Проте, я не намагався пояснювати чи нав’язувати іншим (тим паче лідам), як робити цю роботу. Моїм завданням було якось осмислити той справді невеликий досвід, що я отримав за ці 6 місяців, і поділитись ним — не у вигляді догми, а лише певних висновків, щодо яких можна дискутувати.

    Мені здається, що цей матеріал більш цікавий не для лідів, а для розробників, які хочуть розвиватися в цьому напрямку — тому навіть базові для досвідчених лідів речі можуть бути корисними.

  • Не разработчик и не менеджер. Что означает быть лидом

    Погоджуюсь с кожним пунктом. Хоча, з 5м у мене складніше — все ж таки я людина й усе людське мені не чуже :)

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

    Игнат, у меня нет огромного опыта найма людей в свои / чужие команды и компании, но немного с этим я уже столкнулся. Мне кажется, что вы (как это не забавно) переоцениваете значение объективности при оценке специалиста (спойлер: её не бывает).

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

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

    Нанимая к себе в команду, я в первую очередь оцениваю, может ли человек делать работу, которую нужно — то есть, оцениваю хард скилы не «объективно», а ситуационно, относительно целей и ожиданий здесь и сейчас + пару месяцев вперед (что, мне кажется, валидно и для стартапа). Также, думаю впишется ли этот человек в команду и будет ли мне и остальным с ним комфортно работать.

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

    Bottomline: не ищите лучших. Ищите тех, кто подходит вам сейчас, с кем вам комфортно работать, и растите вместе с ними.

← Сtrl 12 Ctrl →