Прошу консультации у тим лидов, которые работают/работали на реальных проектах на этой позиции в офисе, что важно. Дело в том, что весь мой многолетний опыт сводится к фрилансу и удаленке. Лидерством тоже там занимался, но не так чтобы системно, а скорее человек-оркестр, который и там и здесь.
Как работает тим лид в офисе на больших проектах я в своей жизни не видел. Соответственно идя на эту позицию, незнаю чего ожидать. По разным постам и комментариям друзей, выделил для себя несколько категорий вопросов, которые хотел бы прояснить у уважаемых коллег. Если что, размер команды 6-8 человек включая джунов и стажеров. Аутсорс. Проект новый.
Общие вопросы
Какие в задачи в целом, должен решать тим-лид? Я понимаю, есть универсальный ответ — все зависит от проекта. В конторе X, он пиццу носил для сплочения коллектива, а в конторе Y, решает финансовые вопросы с заказчиком. Но все же, как у вас?
В чем отличие тим лида от архитектора или PM'a?. Разве лид не должен решать архитектурные вопросы? Разве не должен создавать распределять таски?
Распределение задач
1. Что делать с джуниорами? Какие задачи им назначать?
2. Что делать со стажерами? Тот же вопрос.
3. Как по науке распределять задачи между мидлами и сеньорами? На интервью я сказал, что нужно выделить часть проекта, за которую человек отвечает, максимально независимую от остальных, и пусть совершенствует свою песочницу общаясь с другими через интерфейсы. Это решение похоже на идеального коня в вакууме, и PM неодобрительно покачал головой. Но а как правильно?
Организация процессов (SCRUM)
Проект будет по Скраму двигаться вперед, что это такое — я знаю, но не эксперт. А неясные вопросы по организации процессов есть такие.
— Code Review, CI и билды, заполнять SCRUM-боард тасками и спринтами — это взять на себя или переложить на PM'a. Есть вероятность, что соглашаясь на все можно перегореть, от количества обязанностей. В оффере мне сказали, что кодинг/организация будет 50/50%. Если будет куча разноплановых задач — то спать в офисе станет привычкой.
Разработка архитектуры
* Какие инструменты и какие подходы вы используете у себя?
* Что посоветуете почитать, посмотреть или лучше пройти курс?
* Что лучше При реализации — писать свои велосиепеды или искать и изучать 3rd party решения. Мне сказали, что за open-source 3rd party никто ответственности не несет, поэтому спросить не с кого будет. Но скажем, я хочу использовать MVVM Light, чем писать все вручную, разве плохо? Библиотека отлажена и используется тысячами если не миллионами разрабов по всему миру.
Митинги и общение с заказчиком
* Это будет ежедневный процесс, и как говорят мои знакомые, часто возникает конфликт, между хотелками заказчиков и ресурами команды, а также качестом. Как решать?
* Что в целом посоветуете на митингах? Ранее на удаленке, я мог рассказывать басни, что все прекрасно и процесс идет, вот вот доделаю. Что было не всегда было правдой.
Хотелось понять как не завернуть проект в сторону, что хочет заказчик — так и пляшем. Неважно будет уже, и архитектура и покрытие тестами и в целом качество, главное успеть его удовлетворить. В корне не хотелось бы такого, иначе работа будет ад и я уйду опять в свою берлогу фрилансить.
Изините грешного за такой объем поста и множества вопросов, но мне очень важно узнать ваш опыт.
Я так понял что тебя кидают тех. лидом к иностранному заказчику на проект, тогда в таком случае PM это иностранный заказчик, а ты архитект, бизнес-аналитик и самый прошаренный программист команды в одном лице.
Здравствуйте, turbocode, Вы писали:
T>Здравствуйте, licedey, Вы писали:
T>Я так понял что тебя кидают тех. лидом к иностранному заказчику на проект, тогда в таком случае PM это иностранный заказчик, а ты архитект, бизнес-аналитик и самый прошаренный программист команды в одном лице.
Ну во-первых не кидают, а я сам к ним пошел на эту должность А во-вторых, PM — это другой человек, а я по-видимому отвечаю за организацию процессов, архитектуру и лезу в код , когда есть возможночть
Здравствуйте, licedey, Вы писали:
L>Прошу консультации у тим лидов, которые работают/работали на реальных проектах на этой позиции в офисе, что важно. Дело в том, что весь мой многолетний опыт сводится к фрилансу и удаленке. Лидерством тоже там занимался, но не так чтобы системно, а скорее человек-оркестр, который и там и здесь.
На часть вопросов и неопределенность — отвечает эта статья. Но так или иначе, ваш опыт работы тим лидом — уникален и интересен.
Здравствуйте, licedey, Вы писали:
L>Как работает тим лид в офисе на больших проектах я в своей жизни не видел. Соответственно идя на эту позицию, незнаю чего ожидать. По разным постам и комментариям друзей, выделил для себя несколько категорий вопросов, которые хотел бы прояснить у уважаемых коллег. Если что, размер команды 6-8 человек включая джунов и стажеров. Аутсорс. Проект новый.
Сразу пара вопросов, чтобы лучше понимать ситуацию:
* Какой тип проекта — Time & Material? Или Fixed Cost/Scope/Time?
* Какой домен?
Теперь поделюсь своим ИМХО по твоим вопросам.
Насчет синьор/мидл/джуниор ролей — лично я их трактую так:
* Синьор — опытный и ответственный человек, которому я могу дать достаточно большую и возможно не совсем четко сформулированную задачу. Он ее проанализирует, декомпозирует на подзадачи и сделает. В случае проблем эскалирует их лиду. Со стороны лида нужен минимальный надзор.
* Мидл — человек с опытом, но задачи которому нужно ставить по возможности четкие и сформулированные. Мидлу нужен более плотный контроль и возможно понадобиться помощь с начальным анализом/выработкой оптимального решения.
* Джуниор — человек без опыта или с минимальным опытом. За ним нужен надзор, обучение. Можно давать какие-то совсем простые задачи, к которым у остальных не доходят руки. Джуниора можна отдать в качества помощника синьору, который будет его менторить и давать задачи из своей зоны ответственности.
* Стаже — не уверен, что здесь имеется в виду. Но если, это что-то вроде студента-практиканта, то я бы таких и близко не подпускал на свой проект.
Если говорить коротко — то если джуниор, зафакапит задачу, то я даже не удивлюсь. Если мидл зафакапит задачу, то это мой провтык, т.к. не отследил вовремя. Если синьор зафакапит задачу, то это тоже мой провтык (т.к. я тим лид), но я серьезно поговорю с этим человеком.
Насчет архитектуры системы:
* Инструменты советовать не буду, т.к. это сильно зависит от типа системы.
* Насчет разбиения по компонентам и их изоляции с помощью строгих API. На мой взгляд, с одной стороны, это отличная практика и я именно так и делаю на своих проектах. С другой стороны, мой опыт говорит, что успеха добиваются чаще кросс-функциональные команды. Т.е. условно говоря, если есть система, которая состоит из трех компонент — базы данных, бэкэнда и юзер интерфейса, то лучше не делать так, чтобы было три отдельные команды, каждая их которых отвечает за свой компонент. Т.к. любая задача, которая затрагивает все три компонента, приведет к огромному оверхеду на коммуникацию, взаимную приоритезацию, задержки и т.д. Вы идеале я бы предпочел работать с full-stack разработчиками. Но в любом случае в скрам-команде должны быть люди, которые могут работать с любой частью системы. Конечно, бывают исключения — например, высоконагруженная база данных, где нужны выделенные БД разработчики. Но все же кросс-функциональные команды в моей практике показали себя лучше, чем матричные структуры.
* Бытует мнение, что в Аджайле можно не заморачиваться особо насчет архитектуры и просто пилить код ведь "working software is uber alles". Мне это кажется неправильным и если нет возможности продумать архитектуру, то всегда нужно закладывать некоторый архитектурный люфт в систему. У меня был опыт с проектом, где архитектура лепилась на коленке по ходу дела ("software is grown, not built"). С одной стороны, этот проект счастливо сейчас крутиться в продакшн. С другой стороны, через год разработки стоимость изменений в него взлетела до небес и приходилось все больше и больше времени тратить на рефакторинги.
Что касается скрам-процесса. Я не знаю, какая у вас специфика проекта (может вся документация готова и ПМ все досконально проработал. Но все же несколькими наблюдениями могу поделиться:
* Сразу требуй нормального Product Owner в свою команду. В идеале это должен быть представитель заказчика, который будет служить посредником между вашей командой и пользователями/стейкхолдерами со стороны клиента. Мои требования к ПО — он должен обладать правом принимать executive решения по вашему проекту. Он должен быть экспертом в предметной области. Он должен быть положительно заинтересован в вашем проекте (т.е. радеть за его успех). Он должен выделить достаточно времени на ваш проект. В идеале он должен сидеть прямо рядом с вашей командой. Если это не возможно физически, то он должен всегда быть доступен по телефон / через видео-связть. Кстати, насчет Proxy Product Owner — когда роль ПО выполняет кто-то из членов вашей команды (например, тим лид или бизнес аналитик). Мне такой подход не очень нравиться, т.к. в итоге все равно получается испорченный телефон.
L>Ну во-первых не кидают, а я сам к ним пошел на эту должность А во-вторых, PM — это другой человек, а я по-видимому отвечаю за организацию процессов, архитектуру и лезу в код , когда есть возможночть
Сильно зависит от качества команды, если тебе кинут десяток джунов (которых выдадут заказчику за синьоров) то кодить тебе придется больше всех.
Здравствуйте, licedey, Вы писали: L>Какие в задачи в целом, должен решать тим-лид?
во-первых, тимлид в российской и американской компании занимается совсем другими вещами. но в общем слуае он должен начать с того, чтобы очень подробно познакомиться с начальством и выяснить чего оно на самом деле хочет. всегда есть какие-то политические причины, до которых никогда логикой не додумаешься и которые нужно выпытывать в личных разговорах.
L>В чем отличие тим лида от архитектора или PM'a?. Разве лид не должен решать архитектурные вопросы? Разве не должен создавать распределять таски?
как минимум он должен быть в курсе чем занимается его команда. иногда только этого от него и требуют
L>
Распределение задач
L>1. Что делать с джуниорами? Какие задачи им назначать? L>2. Что делать со стажерами? Тот же вопрос.
не брать. тем более пока сами со всем не разобрались
L>3. Как по науке распределять задачи между мидлами и сеньорами? На интервью я сказал, что нужно выделить часть проекта, за которую человек отвечает, максимально независимую от остальных, и пусть совершенствует свою песочницу общаясь с другими через интерфейсы. Это решение похоже на идеального коня в вакууме, и PM неодобрительно покачал головой. Но а как правильно?
он покачал головой, потому что разработчик может уйти. поэтому лучше не допускать, когда в чем-то разбирается только 1 человек в команде
L>
Организация процессов (SCRUM)
L>Проект будет по Скраму двигаться вперед, что это такое — я знаю, но не эксперт. А неясные вопросы по организации процессов есть такие. L>- Code Review, CI и билды, заполнять SCRUM-боард тасками и спринтами — это взять на себя или переложить на PM'a. Есть вероятность, что соглашаясь на все можно перегореть, от количества обязанностей. В оффере мне сказали, что кодинг/организация будет 50/50%. Если будет куча разноплановых задач — то спать в офисе станет привычкой.
подход зависит от уровня конмады
L>
Разработка архитектуры
L>* Какие инструменты и какие подходы вы используете у себя?
это надо выяснять скорее у компании
L>
Митинги и общение с заказчиком
L>* Это будет ежедневный процесс, и как говорят мои знакомые, часто возникает конфликт, между хотелками заказчиков и ресурами команды, а также качестом. Как решать?
зависит от культуры. в России тилид стоит на стороне команды. в Америке — на стороне заказчика.
L>Хотелось понять как не завернуть проект в сторону, что хочет заказчик — так и пляшем. Неважно будет уже, и архитектура и покрытие тестами и в целом качество, главное успеть его удовлетворить. В корне не хотелось бы такого, иначе работа будет ад и я уйду опять в свою берлогу фрилансить.
поэтому надо как можно ближе познакомиться с заказчиком, чтобы уметь с ним договориться
Здравствуйте, Джеффри, Вы писали:
Д>Здравствуйте, licedey, Вы писали:
L>>Как работает тим лид в офисе на больших проектах я в своей жизни не видел. Соответственно идя на эту позицию, незнаю чего ожидать. По разным постам и комментариям друзей, выделил для себя несколько категорий вопросов, которые хотел бы прояснить у уважаемых коллег. Если что, размер команды 6-8 человек включая джунов и стажеров. Аутсорс. Проект новый.
Д>Сразу пара вопросов, чтобы лучше понимать ситуацию:
Д>* Какой тип проекта — Time & Material? Или Fixed Cost/Scope/Time? Д>* Какой домен?
Спасибо за развернутый ответ. Какой тип проекта — я незнаю, но предполагаю что Time&Material, т.к. заказчик очень крупный и часть команды сидит в США, и аутсорсят большую часть в Украину. На что это может повлиять? Сроки, зарплаты?
Домен — нефть и газ. Обещали специалиста по домену.
Сам проект — десктоп приложение на WPF для визуализации данных (показаний датчиков) и сбора статистики.
Здравствуйте, Джеффри, Вы писали:
Д>(продолжение следует)
Дальше по ролям:
* Насколько я помню, в теории, на скрам-проекте может не быть тим. лида, но должен присутствовать скрам-мастер, который будет следить за соблюдением процесса. Либо может быть и лид, и скрам-мастер. Мне лично, последний вариант не нравится, т.к. он приводит к некоему двоевластию и иногда конфликтам. Поэтому я предпочитаю брать на себя роль скрам-мастера. Но нужно всегда помнить, что одна из задач СМ — это защищать свою команду от заказчика и не прогибаться под него во вред людям. Поэтому если тим-лид склонен соглашаться с ПО, бывает полезно иметь отдельного СМ, который может сказать "нет".
* Далее по выделенным ролям — хорошо иметь бизнес-аналитика, который будет экспертом в предметной области и сможет лучше доносить требования ПО до девелоперов. Также хорошо иметь своих QA тестировщиков в команде (и заодно учить их автоматизации).
* Что касается девелоперов, как я уже писал выше, мне нравится работать с full-stack разработчиками, если это возможно.
Насчет митингов. На мой взгляд, главное здесь, чтобы их было как можно меньше. Не знаю, как у других, но в нашей компании, работа тим-лида — это какой-то митинг-ад. Поэтому я стараюсь по максимуму реджектить митинги, не перегружать ими команду (в этом случае, пусть лучше один человек целый день просидит на митингах, чем вся команда пол-дня) и делать их как можно короче. Из того что необходимо на мой взгляд (внутри команды) по скраму:
* Дейли-стэндап. Каждый говорит быстро, кратко, по сути, без отвлечений. Если нужно что-то обсудить — обсуждается лицом-к-лицу сразу после стэндапа. На мой взгляд, тим-лид должен во время стэндапа убедиться, что люди действительно двигаются по задачам спринта и не отвлекаются на что-то постороннее (burndown chart). Кстати, тут было обсуждение темы мироменеджмента, так вот, на мой взгляд, в отношении мидлов и синьоров — небольшой "пуш" вполне допустим и даже полезен. Т.к. позволяет держать их в тонусе и показывает, что то что они делают действительно важно кому-то еще.
* Ретроспектива. Я лично обожаю этот митинг, лично мой опыт показывает, что он позволяет очень круто снизить напряжение/конфликты в команде и в то же время очень способствует вовлечению людей в работу. Классический формат — Что было хорошо / Что было плохо / Что улучшить — на мой взгляд, самое то.
* Планирование. Опять таки, в теории, ПО заполняет бэклог задач и определяет их приоритеты. Во время планирования, команда собирается берет задачи по приоритетам и оценивает их. В моей практике, я все же использую более директивный подход, когда я просматриваю задачи сам, примерно представляю кто их будет делать и сколько это займет. А потом во время планированию уже веду дискуссию с командой. Мне кажется, здесь важно не только набрать задач, но и дать команде понять куда двигается проект в целом, т.е. показать как каждая сторя ложиться на план проекта. И, конечно, мотивация — "ну, надо братцы. вам не надо, мне надо". Также важно не допускать, чтобы спринт перегружался задачами. В моей практике, девелоперы очень часто бывают оптимистичными в оценке и наборе задач. Здесь, мне кажется, лучше взять меньше и сделать все хорошо, а потом добраться из бэклога. Чем набрать много задач, а потом их из скопа выбрасывать. Хотя второй способ иногда позволяет сделать больше, но происходит это чаще всего в ущерб качеству. Простейший инструмент здесь — это sprint velocity.
* Демо митинги. У меня они всегда очень скомканными получаются, но такая специфика системы, что она просто делает расчеты, которые сложно нормально продемонстрировать. Но тем не менее митинг полезный, т.к. позволяет держать всех в курсе изменений.
* Периодические бэклог груминги. Я их предпочитаю делать сам или вместе с ПО. Вообще, на мой взгляд, очень важно держать бэклог в хорошем состоянии и прививать команде правильную JIRA-культуру.
И пара слов насчет коммуникации с заказчиком. Правильная коммуникация — здесь критически важна. Я видел проекты, у которых был отвратительный менеджмент и постоянные фейлы с деливери, но они были на хорошем счету у клиентов, т.к. на той стороне был какой-нибудь ПМ, который каждый день ходил обедать с заказчиком и просто разговаривал с ним. И точно также я видел проекты, где все было более-менее ок, но они были на плохом счету, т.к. интроверт-тимлид ни с кем не разговаривал. Так что если у тебя скилл общения не очень (особенно на английском, что может быть естественно), найди кого-нибудь кто будет постоянно в контакте с людьми с той стороны.
И, кстати, вообще культурные особенности на таких проекта бывают очень важны. Если там будет русский/украинец, то считай повезло. Если будет какой-нибудь индус, подумай, как нормально выстроить с ним общение.
Здравствуйте, Джеффри, Вы писали:
Д>(продолжение следует)
Напоследок некоторый общие замечания:
* Продумай стратегию релизов и тестирования. Очень хорошо, если получится релизить код на продакшн, после каждого спринта (например, каждые две недели). С одной стороны, это дисциплинирует команду. С другой стороны, это производит очень хорошее впечатление на заказчика. Соответственно, если вы даже зафейлите какой-то кусок функционала в одном спринте, то заказчик это воспримет спокойно, т.к. будет знать, что получить его через две недели.
* Старайся держать фокус команды. Кмк, лучше не распыляться на большое кол-во задач, а лучше всем навалиться на одну задачу и сделать ее сразу. Если в одном спринте команда будет перегружена, постарайся след. спринт сделать разгрузочным. Иначе люди быстро выгорят и не смогут поддерживать sustainable pace.
* Насчет CI/билдов/авто-тестов — обязательно продумай это с самого начала, потом по ходу дела это окупится стократ. У нас для этого дела была отдельная команда ДевОпс, если у вас такого не будет, то придется сделать самому. Но скорей всего, в компании уже будут какие-то стандартные инструменты — JIRA, Confluence, Git, Jenkinks, TeamCity, Nexus, Artifactory, SonarQube, etc. Обязательно настройте нормально интеграцию между всеми ними, чтобы например все комиты были привязаны к JIRA тикету и были видны в билдах и т.д.
* Насчет code review — сделай обязательным ревью при коммите в основной бранч и пусть люди в команде ревьювят код друг-друга.
Я сознательно опускаю моменты связанные со стартом проекта, т.к. не знаю на какой он стадии и что уже сделано, а что еще нужно сделать.
И в завершение насчет главного вопроса — "Хотелось понять как не завернуть проект в сторону, что хочет заказчик — так и пляшем". У меня нет на него четкого ответа, т.к. я сам постоянно сталкиваюсь с ситуациями, когда приходится прогибаться под заказчика (а что делать, если он деньги платит и музыку заказывает?). Но лично я бы попробовал в самом начале, как только начнут возникать такие ситуации сделать такой жесткий push back. Например, я был свидетелем, когда на одном проекте product owner тупил с бэклогом и планированием спринтов. На что тим лид, когда не было понятно какие бизнес фичи нужны для очередного спринта, тупо сделал пустой спринт без единой задачи и написал письмо на всех, где просто указал, что спринт начался, задач нет, т.к. ПО ничего не сделал, команда девелоперов будет отдыхать. Казалось бы в такой ситуации, этого тим. лида должны были бы четвертовать, но нет. ПО всполошился, быстро набросал требований и в следующие спринты уже делал все вовремя и нормально взаимодействовал с командой.
L>Какие в задачи в целом, должен решать тим-лид? Я понимаю, есть универсальный ответ — все зависит от проекта. В конторе X, он пиццу носил для сплочения коллектива, а в конторе Y, решает финансовые вопросы с заказчиком. Но все же, как у вас?
L>В чем отличие тим лида от архитектора или PM'a?. Разве лид не должен решать архитектурные вопросы? Разве не должен создавать распределять таски?
Архитектор -- технический специалист, руководитель проекта -- администратор, разработчики -- исполнители, а ведущий программист -- это связующее звено между ними, контроллер, так сказать.
L>
Распределение задач
L>1. Что делать с джуниорами? Какие задачи им назначать? L>2. Что делать со стажерами? Тот же вопрос. L>3. Как по науке распределять задачи между мидлами и сеньорами? На интервью я сказал, что нужно выделить часть проекта, за которую человек отвечает, максимально независимую от остальных, и пусть совершенствует свою песочницу общаясь с другими через интерфейсы. Это решение похоже на идеального коня в вакууме, и PM неодобрительно покачал головой. Но а как правильно?
Да, должна быть взаимозаменяемость так, чтобы отряд не заметил потери бойца. Ведущий программист -- руководитель, следовательно, он должен уметь и распределять задачи, и делегировать полномочия. Возьмите старших разработчиков и прикрепите к ним младших, этим группкам лучше отдать большие куски, пусть дробят внутри. Средним программистам -- средние задачи.
L>
Организация процессов (SCRUM)
L>Проект будет по Скраму двигаться вперед, что это такое — я знаю, но не эксперт. А неясные вопросы по организации процессов есть такие. L>- Code Review, CI и билды, заполнять SCRUM-боард тасками и спринтами — это взять на себя или переложить на PM'a. Есть вероятность, что соглашаясь на все можно перегореть, от количества обязанностей. В оффере мне сказали, что кодинг/организация будет 50/50%. Если будет куча разноплановых задач — то спать в офисе станет привычкой.
Всю администрацию и переговоры с клиентом/начальством -- руководителю проекта. Проверка кода -- только себе, это самое главное.
L>
Разработка архитектуры
L>* Какие инструменты и какие подходы вы используете у себя?
Если в конторе Скрам, то брать всё самое новое и модное.
L>* Что посоветуете почитать, посмотреть или лучше пройти курс?
SaaS, облако, Big Data. Loosely coupled, rich client... Дальше не могу -- вырвет на монитор.
L>* Что лучше При реализации — писать свои велосиепеды или искать и изучать 3rd party решения. Мне сказали, что за open-source 3rd party никто ответственности не несет, поэтому спросить не с кого будет. Но скажем, я хочу использовать MVVM Light, чем писать все вручную, разве плохо? Библиотека отлажена и используется тысячами если не миллионами разрабов по всему миру.
Переложите это решение на заказчика. У сторонних продуктов есть одно преимущество: дешевле. Ну, и в резюме не повредит добавить модные слова, в самом деле, на "писал свою ORM" никакой робот внимания не обратит.
L>
Митинги и общение с заказчиком
L>* Это будет ежедневный процесс, и как говорят мои знакомые, часто возникает конфликт, между хотелками заказчиков и ресурами команды, а также качестом. Как решать?
Если это ежедневный процесс, то крепитесь. Всё, что можно посоветовать -- это требовать выдавать все пожелания в письменной форме. Это сразу снижает и энтузиазм, и последующие "вы меня не так поняли".
А мастерство специалиста и состоит как раз в том, чтобы понять, что нужно заказчику ещё до того, как это придёт тому в голову. Насчёт качества не забивайте себе голову -- бОльшая часть "хотелок" оказывается ненужной ещё до их выката. Главное -- тщательно изолировать отдельные компоненты, лучше битумом, но на худой конец инкапсуляцией, чтобы выдёргивание маленькой "фичи" не разрушало весь карточный домик.
L>* Что в целом посоветуете на митингах? Ранее на удаленке, я мог рассказывать басни, что все прекрасно и процесс идет, вот вот доделаю. Что было не всегда было правдой.
Продолжайте в том же духе. Побольше картинок, презентаций, графиков надоев говядины и т. п. И всегда давайте заказчику полностью высказаться -- они экономят на психотерапевте.
L>Хотелось понять как не завернуть проект в сторону, что хочет заказчик — так и пляшем. Неважно будет уже, и архитектура и покрытие тестами и в целом качество, главное успеть его удовлетворить. В корне не хотелось бы такого, иначе работа будет ад и я уйду опять в свою берлогу фрилансить.
"Кто девушку ужинает, тот её и танцует". Это и есть профессионализм -- сделать то, что хочет/нужно заказчику, невзирая на свой PMS. А не втюхивать с видом артиста больших и малых театров то, что нравится самому.
L>Изините грешного за такой объем поста и множества вопросов
Здравствуйте, licedey, Вы писали:
L>Спасибо за развернутый ответ. Какой тип проекта — я незнаю, но предполагаю что Time&Material, т.к. заказчик очень крупный и часть команды сидит в США, и аутсорсят большую часть в Украину. На что это может повлиять? Сроки, зарплаты?
T&M — должен быть ок. Наоборот, в твоем положение было бы самоубийством подписаться на реальный Fixed Cost.
В рамках T&M — главное, чтобы заказчик был доволен как идет проект (= платил деньги и продлевал контракт), а тимлид должен делать свою работу настолько хорошо, насколько он способен.
В теории, за Fixed Cost платят больше и больше полномочий у тимлида, но и все риски на нем (хотя скорее на компании, но это не так важно, т.к. с тимлида обязательно спросят тоже).
L>Домен — нефть и газ. Обещали специалиста по домену. L>Сам проект — десктоп приложение на WPF для визуализации данных (показаний датчиков) и сбора статистики.
В принципе, тоже ок. Мне кажется, что core системы для таких доменов как health care или финансы, могут привести к тому, что легковесный Agile превратиться в какую-то более формальную модификацию а-ля managed agile with tribes, с внешними аудиторами в придачу.
L>Жду продолжения
Уже. Кстати, буду благодарен, если через некоторое время ты напишешь пост на тему насколько то, что люди здесь написали совпало с тем, что в реальности происходит на твоем проекте.
Здравствуйте, Джеффри, Вы писали:
Д>Вы идеале я бы предпочел работать с full-stack разработчиками. Но в любом случае в скрам-команде должны быть люди, которые могут работать с любой частью системы. Конечно, бывают исключения — например, высоконагруженная база данных, где нужны выделенные БД разработчики.
Практика показывает, что при команде, состоящей только из full-stack разработчиков, практически любая БД через год-два превращается в "высоконагруженную", т.е., испытывающую проблемы с выдерживанием текущей (обычно, весьма умеренной) нагрузки. Поэтому полезно запланировать найм такого специалиста в означенный срок, а заодно и ресурсы для рефакторинга системы. Раньше этого срока убедить в необходимости специалиста по БД бывает затруднительно.
Здравствуйте, licedey, Вы писали:
L>Прошу консультации у тим лидов, которые работают/работали на реальных проектах на этой позиции в офисе, что важно. Дело в том, что весь мой многолетний опыт сводится к фрилансу и удаленке. Лидерством тоже там занимался, но не так чтобы системно, а скорее человек-оркестр, который и там и здесь. L>Как работает тим лид в офисе на больших проектах я в своей жизни не видел. Соответственно идя на эту позицию, незнаю чего ожидать. По разным постам и комментариям друзей, выделил для себя несколько категорий вопросов, которые хотел бы прояснить у уважаемых коллег. Если что, размер команды 6-8 человек включая джунов и стажеров. Аутсорс. Проект новый.
Во всех конторах всё это по-разному. Обговаривайте с конторой чем вы будете заниматься и за что с вас будет спрос. Мало что вам дадут статьи и курсы, баззворды типа скрам везде повторяют но везде понимают по-разному.
На мой взгляд если это аутсорс, то ваш фрилансерский опыт лучше некуда.
> Как по науке распределять задачи между мидлами и сеньорами? На интервью я сказал, что нужно выделить часть проекта, за которую человек отвечает, максимально независимую от остальных, и пусть совершенствует свою песочницу общаясь с другими через интерфейсы. Это решение похоже на идеального коня в вакууме, и PM неодобрительно покачал головой. Но а как правильно?
Мидлам задачи попроще, синьорам посложнее, ежедневные собрания у кого какие вопросы, у кого как дела. Личная ответственность за результат каждому (надо каждому донести понимание, что пострадает команда). Своя песочница с интерфейсами каждому — на практике такого не видел, да и не нужно это. Интерфейсы между крупными блоками, а не участками отдельных разработчиков.
Как у кого выглядит такой процесс как "разработка архитектуры" с удовольствием бы посмотрел. То что до сих пор видел сильно расходилось с моими представлениями. Как-то эта "разработка архитектуры" чересчур укрупнённо была, типа есть много серверов, тут вот балансировщик, данные в БД шардятся, кеш в редисе сбоку общий для всех. все данные в json. аутентификация по SAML. Вся проработка архитектуры Занимались ей отнюдь не самые сильные технари. Либо самый крутой разраб половину продукта пишет один, остальные потом дописывают в эту архитектуру своё. Как у кого это выглядит, предлагаю делиться наблюдениями.
Здравствуйте, Джеффри, Вы писали:
L>>Спасибо за развернутый ответ. Какой тип проекта — я незнаю, но предполагаю что Time&Material, т.к. заказчик очень крупный и часть команды сидит в США, и аутсорсят большую часть в Украину. На что это может повлиять? Сроки, зарплаты?
В продолжении финансового вопроса, меня немного смутило, что за меня очень вцепились. Выйти я должен был еще в ноябре-начале декабря, но по болезни очухался только к середине декабря и отложил вопрос на январь. И они при всем при этом ждали меня и готовы выплатить бонус за подписание. Они — это HR и PM. Это из-за того, что все в доле? Может ли это означать, что после моего подписания — им вышлют хороший гешефт и я перестану быть таким ценным.
На прямой вопрос "Вам нужна хромая лошадь?", "Вам нужен TL, который часто болеет?" — мне ответили: Вы нам очень нужны! Почему?
Я конечно MVP, 10+ лет опыта, опыт лидерства и своих проектов, но неужто так незаменим. Или грех на душу беру, а сама компания — няшечки.
Д>Уже. Кстати, буду благодарен, если через некоторое время ты напишешь пост на тему насколько то, что люди здесь написали совпало с тем, что в реальности происходит на твоем проекте.
Здравствуйте, Джеффри, Вы писали:
Д>Здравствуйте, licedey, Вы писали:
L>>Почему?
Д>Ну, если вас кто-то действительно рекомендовал их HR-ам, то он действительно получит бонус, скорей всего.
Они сами на меня вышли. А разве PM в аутсорсинге не распоряжается финансовыми ресурсами? Например ему выделят на следующие пол года условных 100k$ на команду.
Не захочет ли он, выдать мидла за сеньора или что-то в таком духе, и взять себе кусочек из бюджета?
Хотя я не маленький, понимаю что и у ПМа есть начальство, есть бухгалтерия, но все же...
Здравствуйте, licedey, Вы писали:
L>Они сами на меня вышли. А разве PM в аутсорсинге не распоряжается финансовыми ресурсами? Например ему выделят на следующие пол года условных 100k$ на команду. L>Не захочет ли он, выдать мидла за сеньора или что-то в таком духе, и взять себе кусочек из бюджета? L>Хотя я не маленький, понимаю что и у ПМа есть начальство, есть бухгалтерия, но все же...
Ну, чтобы прямо себе в карман, то вряд ли. Но менеджер со стороны аутсорсера, конечно, может продать мидла/джуна заказчику как сениора, а потом получить бонусы с прибыли компании за счет возросшей маржи.
В принципе, вполне может быть, что компания продала клиенту команду мидлов/джунов как сеньоров, а теперь срочно ищет с ним опытного лида, чтобы не зафейлить проект. Но это чисто мои измышления, не хочу тебя пугать
L>В чем отличие тим лида от архитектора или PM'a?
Лидиер — это один человек, а само лидерство — процесс социальный, а не технический.
Вожак в стае/капитан комманды, который говорит что сейчас мы идем вот туда, ты делаешь вот то, а ты — вот это.
А ПМ, Архитектор и т.п. — технические роли, которые может исполнять один или несколько человек, попеременно или одновременно.
L>Какие в задачи в целом, должен решать тим-лид?
В целом — ровно одну: эффективность комманды с лидом должна быть намного выше чем без него.
Вообще тебе стоило спросить у твоего начальства какие задачи оно хочет чтобы ты решал, и сделать это _до_ трудоустройства
А во-вторых, PM — это другой человек, а я по-видимому отвечаю за организацию процессов, архитектуру и лезу в код , когда есть возможночть
