Прошу консультации у тим лидов, которые работают/работали на реальных проектах на этой позиции в офисе, что важно. Дело в том, что весь мой многолетний опыт сводится к фрилансу и удаленке. Лидерством тоже там занимался, но не так чтобы системно, а скорее человек-оркестр, который и там и здесь.
Как работает тим лид в офисе на больших проектах я в своей жизни не видел. Соответственно идя на эту позицию, незнаю чего ожидать. По разным постам и комментариям друзей, выделил для себя несколько категорий вопросов, которые хотел бы прояснить у уважаемых коллег. Если что, размер команды 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>Какие в задачи в целом, должен решать тим-лид?
В целом — ровно одну: эффективность комманды с лидом должна быть намного выше чем без него.
Вообще тебе стоило спросить у твоего начальства какие задачи оно хочет чтобы ты решал, и сделать это _до_ трудоустройства
L>>Какие в задачи в целом, должен решать тим-лид? R>В целом — ровно одну: эффективность комманды с лидом должна быть намного выше чем без него. R>Вообще тебе стоило спросить у твоего начальства какие задачи оно хочет чтобы ты решал, и сделать это _до_ трудоустройства
Я спрашивал, уточнял и не раз. Но все проясниться на месте, поэтому спрашиваю про чужой опыт. Видите слово "в целом?".
Здравствуйте, licedey, Вы писали:
L>Прошу консультации у тим лидов, которые работают/работали на реальных проектах на этой позиции в офисе, что важно. Дело в том, что весь мой многолетний опыт сводится к фрилансу и удаленке. Лидерством тоже там занимался, но не так чтобы системно, а скорее человек-оркестр, который и там и здесь. L>Как работает тим лид в офисе на больших проектах я в своей жизни не видел. Соответственно идя на эту позицию, незнаю чего ожидать. По разным постам и комментариям друзей, выделил для себя несколько категорий вопросов, которые хотел бы прояснить у уважаемых коллег. Если что, размер команды 6-8 человек включая джунов и стажеров. Аутсорс. Проект новый.
L>Какие в задачи в целом, должен решать тим-лид?
Задач дофига, но главные это то что лид проекта должен уметь делегировать задачи на своих синьоров, и знать трудоемкость их решаемых задач.
L>В чем отличие тим лида от архитектора или PM'a?.
Две совершенно разные роли на проекте, по должностной матрице нередко выполняет один и тот же человек.
L>1. Что делать с джуниорами? Какие задачи им назначать?
На проекты, длительностью до одного года не брать. На длительные проекты — обучать.
L>2. Что делать со стажерами? Тот же вопрос.
Не брать ни при каких вариантах. "Заворачивать" на уровне формирования вакансии. Пусть "стажируются" в ВУЗе или у мамки своей.
L>3. Как по науке распределять задачи между мидлами и сеньорами?
Никакие задачи между синьйорами и мидлами не распределаются. Это абсурд. Синьер выполняет важнейшие задачи проекта и следит за мидлом чтоб он выполнял свои задачи. А вот синьора контролирует лид.
L>- Code Review, CI и билды, заполнять SCRUM-боард тасками и спринтами — это взять на себя или переложить на PM'a.
Все эти задачи не ПМ, а лидовские.
L>* Какие инструменты и какие подходы вы используете у себя?
Excel для расчета стоимости, для планирования и всего остального лично я использую OmniPlan — затем переношу все в JIRA
L>* Что посоветуете почитать, посмотреть или лучше пройти курс?
PMBOK
L>* Что лучше При реализации — писать свои велосиепеды или искать и изучать 3rd party решения.
3rd party
L>Мне сказали, что за open-source 3rd party никто ответственности не несет, поэтому спросить не с кого будет.
Кто сказал? Мамкины борщехлебы? Они готовы из своего кармана бабло заплатить за велосипеды или только теоретики?
L>Но скажем, я хочу использовать MVVM Light, чем писать все вручную, разве плохо?
Лучше сэкономить на времени разработки чем на зарплатах личного состава. Или нанять еще людей.
L>Библиотека отлажена и используется тысячами если не миллионами разрабов по всему миру.
Забей на мнение мамкиных борщехлебов. Исходя из личного опыта в больших проектах (там где членами команды было написано от 1млн строк кода и выше) 75%-80% остального кода это результат работы не членов команды.
L>* Это будет ежедневный процесс, и как говорят мои знакомые, часто возникает конфликт, между хотелками заказчиков и ресурами команды, а также качестом. Как решать?
Вообще-то общение с заказчиками делает исключительно ПМ, или бизнес-аналитик, или аккаунт менеджер или BDO, но точно не лид. Если лид начинает общатся с заказчиком, то это значит что ПМ положил на проект либо на заказчик сует свой сопливый нос в проект (у меня обычно происходило когда заказчики евреи были, те были "экпертами во всем", но то к теме не относится).
Так вот, вариант — выгонять на выходные всю команду — пусть херячат на благо великого ПМа (как ниже я замечу заказчик здесь никаким боком). Тебе за успех проекта, как начинающему лиду, скажут "спасибо и хорошего настроения", а вот у 99% ПМ есть премия за не срыв сроков.
L>* Что в целом посоветуете на митингах? Ранее на удаленке, я мог рассказывать басни, что все прекрасно и процесс идет, вот вот доделаю. Что было не всегда было правдой.
Продолжай рассказывать басни о том, что ты офигенный лид и знаешь что делаешь, что не просто так занимаешь должность и ты лучшая кандидатура, кого можно было представить за эти деньги.
L>Хотелось понять как не завернуть проект в сторону, что хочет заказчик — так и пляшем.
Да ты и так его завернешь. У вас с заказчиком цели разные. У заказчика — сделать больше за меньшие деньги. А у тебя сделать больше за большие деньги. Чувствуешь разницу? Вы — две стороны одного контракта, говоря простым языком — в твоем лице — исполнительная власть, а заказчик — заканодательная.
L>Неважно будет уже, и архитектура и покрытие тестами и в целом качество, главное успеть его удовлетворить.
1. Во-первых, построил рабочий процесс таким, каким он должен быть. Распределил сферы влияния, назначил смежных спецов на случае болезни/отпуска и т.д.
2. Во-вторых, периодически обучаю свою команду. Раньше они бегали к сеньорам и те решали за них задачи, теперь бегают ко мне, но я их задачи не решаю, а помогаю это делать им самим. Сейчас буду стараться их развивать дальше в техническом плане. Результатом пункта 1 и 2 стало то, что я могу плевать в потолок, а работа всё равно будет делаться. Раньше приходилось давать по рукам, т.к. продакшн падал, а им хоть бы хны. Когда эскалация доходила до VP, пояснял, что так быть не должно и проблема должна решаться в соответствии с SLA/OLA ими самими, либо эскалироваться ими самими, а уж не как не доходить до VP от бизнеса.
3. Поддерживаю приятельские отношения с членами команды, стараюсь сплотить команду, чтобы она работала как единое целое (мы все в разных офисах сидим).
4. Стараюсь раз в год организовать командный сабантуй (т.к. все в разных офисах, это обходится в копеечку)
5. Пятым пунктом должен был стать распределеие ресурсов по проектам, но проектами ведает мой босс и пока не спешит ими делиться.
6. Всякие там утверждения отпусков, командировок и т.д. Каждые 6 месяцев ревью и другая бумажная волокита.
7. Организовал отчётность, которая автоматически высылает каждому сотруднику задачи, которые висят на нём, их статус и так далее (у нас 3 трекинговых системы )
Сейчас стараюсь расширять сферу своего влияния и туда внедрять уже построенные процессы.
L>Какие в задачи в целом, должен решать тим-лид? Я понимаю, есть универсальный ответ — все зависит от проекта. В конторе X, он пиццу носил для сплочения коллектива, а в конторе Y, решает финансовые вопросы с заказчиком. Но все же, как у вас?
Основная задача тимлида делать так чтобы гребцы не посрались и гребли более-менее в одну сторону. Кроме того, на тимлиде лежит ответственность превращать планов громадье менеджера в конкретные задачи для исполнителей и контроллить разрешение этих задач.
L>В чем отличие тим лида от архитектора или PM'a?. Разве лид не должен решать архитектурные вопросы? Разве не должен создавать распределять таски?
Архитектить должен но на низком уровне. Архитект решает на высоком уровне, будет в проекте трехзвенка, толстый клиент или вообще P2P, в тимлид решает как побить фичу на классы. ПМ решает в каком месяце что должно быть готово, а тимлид раздает задачи по неграм.
L>1. Что делать с джуниорами? Какие задачи им назначать?
Багфиксинг, наращивание мяса на скелет. Типа синьор делает прототип, а джун прикручивает обработку ошибок, валидацию входных параметров, тесты и т.п. рутину.
L>2. Что делать со стажерами? Тот же вопрос.
То же самое что и с джуниорами, только задачи брать менее ответственные.
L>3. Как по науке распределять задачи между мидлами и сеньорами? На интервью я сказал, что нужно выделить часть проекта, за которую человек отвечает, максимально независимую от остальных, и пусть совершенствует свою песочницу общаясь с другими через интерфейсы. Это решение похоже на идеального коня в вакууме, и PM неодобрительно покачал головой. Но а как правильно?
Задачи которые могут сделать только синьоры отдавать синьорам. "Могут сделать" означает "могут сделать с должным качеством в нужном объеме за разумный срок". С остальными аналогично вплоть до стажеров.
L>Проект будет по Скраму двигаться вперед, что это такое — я знаю, но не эксперт. А неясные вопросы по организации процессов есть такие. L>- Code Review, CI и билды, заполнять SCRUM-боард тасками и спринтами — это взять на себя или переложить на PM'a. Есть вероятность, что соглашаясь на все можно перегореть, от количества обязанностей. В оффере мне сказали, что кодинг/организация будет 50/50%. Если будет куча разноплановых задач — то спать в офисе станет привычкой.
CR делегируй синьорам, CI и билды это типичная задача для джунов. Короче делегируй что можно делегировать, а оставшееся делай сам. Если ты знаешь что кто-то сделает задачу хуже тебя, все равно отдавай ее ему потому что если ты сам закопаешься в деталях, упустишь контроль над ситуацией.
L>* Какие инструменты и какие подходы вы используете у себя?
Из платформонезависимого глубоко тюненый Redmine, GIT + merge-free gitflow, Jenkins + Docker + Salt.
L>* Что посоветуете почитать, посмотреть или лучше пройти курс?
PmBOK, Жизнь внутри пузыря (для адекватного понимания ожиданий верхнего менеджмента), Office Space (для адекватного понимания настроений подчиненных)
L>* Что лучше При реализации — писать свои велосиепеды или искать и изучать 3rd party решения. Мне сказали, что за open-source 3rd party никто ответственности не несет, поэтому спросить не с кого будет. Но скажем, я хочу использовать MVVM Light, чем писать все вручную, разве плохо? Библиотека отлажена и используется тысячами если не миллионами разрабов по всему миру.
В аутсорсинге плевать. Платит заказчик за велосипед, можно делать велосипед, денег больше будет. Платит за допиливание 3rd party, можно допилпивать 3rd party. По нормальному оно как делается, берешь опен сорс, используешь, если чего не хватает, нанимаешь оригинального разработчика и он быстро и дешево допиливает что тебе нужно. Но в аутсорсинге из заказчика черта с два на такое выбьешь деньги. Приходится своими силами разбираться и допиливать.
L>* Это будет ежедневный процесс, и как говорят мои знакомые, часто возникает конфликт, между хотелками заказчиков и ресурами команды, а также качестом. Как решать?
Торгуйся. Заказчик хочет А? Ок, говоришь ему, но тогда на B и С не хватит денег/времени, давайте решать что важнее.
L>* Что в целом посоветуете на митингах? Ранее на удаленке, я мог рассказывать басни, что все прекрасно и процесс идет, вот вот доделаю. Что было не всегда было правдой.
Планируй показы заказчику промежуточных результатов. Так чтобы было видно что работа идет но еще осталась. Поскольку заказчик оценивает в первую очередь интерфейс тебе придется научиться кое-каким трюкам.
L>Хотелось понять как не завернуть проект в сторону, что хочет заказчик — так и пляшем. Неважно будет уже, и архитектура и покрытие тестами и в целом качество, главное успеть его удовлетворить. В корне не хотелось бы такого, иначе работа будет ад и я уйду опять в свою берлогу фрилансить.
Почему? Заказчик лучше знает какой продукт нужен его бизнесу. Твоя задача и задача команды сделать такую архитектуру, которая позволит как можно дешевле вносить изменения требуемые заказчиками.
Здравствуйте, Джеффри, Вы писали:
Д>Если говорить коротко — то если джуниор, зафакапит задачу, то я даже не удивлюсь. Если мидл зафакапит задачу, то это мой провтык, т.к. не отследил вовремя. Если синьор зафакапит задачу, то это тоже мой провтык (т.к. я тим лид), но я серьезно поговорю с этим человеком.
О чем?
Твой вопрос дает информацию о культуре конторы, людях и о тебе. Есть несколько сигналов, которые я распознал:
Внутреннее качество технических решений занимает последнее место после финансовых показателей и отношений в коллективе. Показателен отказ использовать open-source решения и отказ от разделения труда. Ты же, наоборот, инженер и технический специалист.
Буду отвечать ниже исходя из этого:
Здравствуйте, licedey, Вы писали: L>
Общие вопросы
L>Какие в задачи в целом, должен решать тим-лид? Я понимаю, есть универсальный ответ — все зависит от проекта. В конторе X, он пиццу носил для сплочения коллектива, а в конторе Y, решает финансовые вопросы с заказчиком. Но все же, как у вас?
1. Отслеживать прогресс
2. Знать и быстро отвечать, кто и чем занимается в данный момент
3. Знать о дедлайнах, что нужно завершить для их выполнения и напоминать об этом членам команды.
4. Распознать сильные стороны членов команды и кому, что лучше поручить.
5. Так же, иметь представление об амбициях и обидах ("а почему мне не дали?!") и распределять задачи вызывая минимум истерик.
6. Знать на высоком уровне детали проблем, которые решает команда и участвовать в разговоре.
7. Арбитраж и суд, чье решение или предложение выберем.
8. Хвалить команду и отдельных ее членов, чтобы всем было приятно и никто не завидовал.
9. Напоминать о timesheets, КПА и прочей бюроктатии и уметь писать простыни самому. "Что хорошего можете написать о работе Махмуда за 2016 год?"
10. Быть позитивным, стричься, бриться, аккуратно одеваться и излучать успех. L>В чем отличие тим лида от архитектора или PM'a?. Разве лид не должен решать архитектурные вопросы? Разве не должен создавать распределять таски?
ПМ не знает тех. деталей, а Тим Лид должен разбираться и в технических вещах и в пользовательском домене. ПМ отслеживает и напоминает, Тим Лид делает тоже самое, но еще и принимает решения. L>
Распределение задач
L>1. Что делать с джуниорами? Какие задачи им назначать?
В заграницах Старший Разраб это самая низкая должность. Джуниоров, обычно, быстро повышают или они сами уходят на повышение в другую контору. L>3. Как по науке распределять задачи между мидлами и сеньорами? На интервью я сказал, что нужно выделить часть проекта, за которую человек отвечает, максимально независимую от остальных, и пусть совершенствует свою песочницу общаясь с другими через интерфейсы. Это решение похоже на идеального коня в вакууме, и PM неодобрительно покачал головой. Но а как правильно?
Ты сказал правильно с точки зрения технаря. Для них же, распределение труда это смертный грех. Они хотят заменяемость и ротации. Никто не будет смотреть на качество кода, а если баги, то заказчики позвонят в суппорт и потепят. Убытков, скорее всего от этого не будет. Подыграй им, и в следующий раз следуй аджайлу и скраму. Только фул стек, учимся на ходу, дольше месяца на одном модуле не сидим, книжки не читаем, стек оверфлоу и вперед. Ротации, ротации. Так победим! L>
Организация процессов (SCRUM)
L>Проект будет по Скраму двигаться вперед, что это такое — я знаю, но не эксперт. А неясные вопросы по организации процессов есть такие.
Скрам — это когда не ты ходишь к каждому и спрашиваешь, а они сами приходят каждый день и отчитываются. Кроме того, они друг друга мотивируют, так как отчитываются публично. Peer pressure. Посмотри список вверху. Большое число твоих задач выполняются стендапами с минимальными затратами с твоей стороны. L>- Code Review, CI и билды, заполнять SCRUM-боард тасками и спринтами — это взять на себя или переложить на PM'a. Есть вероятность, что соглашаясь на все можно перегореть, от количества обязанностей. В оффере мне сказали, что кодинг/организация будет 50/50%. Если будет куча разноплановых задач — то спать в офисе станет привычкой.
Забудь про коддинг. Если успеешь, хорошо, но кодинг это теперь, как волонтерство. Тебе платят деньги не за него. Никто не говорит, что ты будешь перерабатывать. Ты будешь мало программировать. L>
Разработка архитектуры
L>* Какие инструменты и какие подходы вы используете у себя?
Нужно задавить свой перфекционизм. Говнокод это норма. L>* Что посоветуете почитать, посмотреть или лучше пройти курс?
Почитай книжку про разные культуры и их отношения на работе. Азиаты, англосаксы и европейцы. Тебе нужно это знать. L>* Что лучше При реализации — писать свои велосиепеды или искать и изучать 3rd party решения. Мне сказали, что за open-source 3rd party никто ответственности не несет, поэтому спросить не с кого будет. Но скажем, я хочу использовать MVVM Light, чем писать все вручную, разве плохо? Библиотека отлажена и используется тысячами если не миллионами разрабов по всему миру.
Понятно, что open source используют все и это лучше. Даже очень важные финансовые компании, где цена ошибки миллионы долларов используют опен сорс. Как можно меньше писать самому. Постарайся убедить начальство. Думаю, что это будет легко. L>
Митинги и общение с заказчиком
L>* Это будет ежедневный процесс, и как говорят мои знакомые, часто возникает конфликт, между хотелками заказчиков и ресурами команды, а также качестом. Как решать?
Не нужно быть слишком честным, как хороший технарь, но и врать уж совсем тоже нельзя. Здесь принято наобещать, а потом рассказывать о непредвиденных проблемах и объяснять почему сроки отодвигаются. Если есть хорошая причина, то конфликтов не будет. L>* Что в целом посоветуете на митингах? Ранее на удаленке, я мог рассказывать басни, что все прекрасно и процесс идет, вот вот доделаю. Что было не всегда было правдой.
Продолжай в том же духе. L>Хотелось понять как не завернуть проект в сторону, что хочет заказчик — так и пляшем. Неважно будет уже, и архитектура и покрытие тестами и в целом качество, главное успеть его удовлетворить. В корне не хотелось бы такого, иначе работа будет ад и я уйду опять в свою берлогу фрилансить.
Именно так и будет. Не будь перфекционистом.
Listen up, maggots. You are not special. You are not a beautiful or unique snowflake. You're the same decaying organic matter as everything else in the world.
Здравствуйте, greenpci, Вы писали:
G>Твой вопрос дает информацию о культуре конторы, людях и о тебе. Есть несколько сигналов, которые я распознал:
Спасибо за ответ, вроде как развернутый. Но форум и для того чтобы спрашивать, неправда ли? Я себя не на помойке нашел, и лидом взяли не просто так. А "контора" — одна из крупнейших в мире в сфере ИТ сервисов.
Здравствуйте, TechL, Вы писали:
TL>Спасибо за ответ, вроде как развернутый. Но форум и для того чтобы спрашивать, неправда ли? Я себя не на помойке нашел, и лидом взяли не просто так. А "контора" — одна из крупнейших в мире в сфере ИТ сервисов.
Всегда рад помочь. Все это выстрадано и получено горьким опытом. Советую прислушаться. Я, как раз, в таких "крупнейших" и работал и информация оттуда.
Как я и писал выше, я распознал, что ты хороший технический специалист, а значит, чем-то похож на меня и цели у тебя похожие. Например, ты ценишь разделение труда, архитектуру, готов отстаивать свои взгляды и т.д.
Не хотелось бы, чтобы ты разочаровался в "крупнейших" конторах, так же тяжело, как это было у меня. Если ты сразу поймешь, что это все театр и будешь знать их настоящие цели, а не то, что они говорят на митингах, то, возможно, всего этого удастся избежать. Может быть, даже сделаешь карьеру и приобретешь эмоциональное равновесие.
Про snowflake это шутка была. Это скорее показывает, что я увидел сам в "крупнейших" конторах. Слова подходят к теме, так как, "личинки мух" копающиеся в говнокоде — это типичная ситуация. Начальство и коллеги намекают словами и действиями, что ты должен присоединиться. Как писал Стауструп — хороший код это статистическая аномалия.
Здравствуйте, TechL, Вы писали:
TL>Я себя не на помойке нашел, и лидом взяли не просто так.
Напрасно ты так реагируешь, человек дело сказал.
Излишне романтическое представление о себе и своей работе — недостаток многих пожизненных удаленщиков.
Первое чему ты должен научиться это здоровый офисный цинизм.
Здравствуйте, Sealcon190, Вы писали:
S>Здравствуйте, TechL, Вы писали:
S>Напрасно ты так реагируешь, человек дело сказал. S>Излишне романтическое представление о себе и своей работе — недостаток многих пожизненных удаленщиков. S>Первое чему ты должен научиться это здоровый офисный цинизм.
Так я с ним вроде и не спорю. Показалось, что меня и компанию немного недооценивают в контексте вопроса. Уточнил.
Что касается романтизма — то он будет наверное всегда. То что мне сейчас приходится пилить — это сложно называть креативом, но что-то там присутствует. Разного рода командные взаимодействия.
Конечно может на Спринте N, это вывестрется...Кстати — что такое здоровый офисный цинизм?)
Здравствуйте, greenpci, Вы писали:
L>>* Что посоветуете почитать, посмотреть или лучше пройти курс? G>Почитай книжку про разные культуры и их отношения на работе. Азиаты, англосаксы и европейцы. Тебе нужно это знать.
Какую-то конкретную посоветуешь?
Здравствуйте, _ABC_, Вы писали:
Д>>Вы идеале я бы предпочел работать с full-stack разработчиками. Но в любом случае в скрам-команде должны быть люди, которые могут работать с любой частью системы. Конечно, бывают исключения — например, высоконагруженная база данных, где нужны выделенные БД разработчики.
_AB>Практика показывает, что при команде, состоящей только из full-stack разработчиков, практически любая БД через год-два превращается в "высоконагруженную", т.е., испытывающую проблемы с выдерживанием текущей (обычно, весьма умеренной) нагрузки. Поэтому полезно запланировать найм такого специалиста в означенный срок, а заодно и ресурсы для рефакторинга системы. Раньше этого срока убедить в необходимости специалиста по БД бывает затруднительно.
Имхо, хороших full-stack разработчиков мало. Может получиться что UI будет кривоватым и неудобным, а код и база будут тормозить (если проект высоконагруженный, а не перебросить 50 записей в день из одного места в другое). У нас на текущем проекте четкое разделение, по-моему нормально работаем.
Здравствуйте, licedey, Вы писали:
L>В чем отличие [b]тим лида от архитектора или PM'a?[/b]. Разве лид не должен решать архитектурные вопросы? Разве не должен создавать распределять таски?
Вообще, это всё -- лишь слова, смысл которых бесконечно размыт...
Здравствуйте, MasterZiv, Вы писали:
L>>В чем отличие [b]тим лида от архитектора или PM'a?[/b]. Разве лид не должен решать архитектурные вопросы? Разве не должен создавать распределять таски?
MZ>Вообще, это всё -- лишь слова, смысл которых бесконечно размыт...
Понимание, основанное на моём опыте (правильность не гарантирую, чистое имхо):
Team-lead: старший разработчик с менеджерскими способностями и обязанностями. Может до половины времени заниматься менеджерством вместо программирования. Распределяет задачи, проверяет прогресс разработчиков и т.д.
Архитектор: нечасто видел отдельную должность архитектора. зачастую архитектурят просто тим-лиды и старшие разработчики, не обязательно в одиночку, иногда вместе продумывая архитектуру.
PM: Насчет работы PM'а у меня, честно говоря, недостаточное представление. Он не кодирует вообще (я не видел по-крайней мере), зачастую является связующим звеном между бизнесом и командной разработки, хотя команда разработки может напрямую общаться с бизнесом если так проще или удобнее. PM общается с бизнесом и тим-лидами, решает что in scope и что out of scope, т.е. например какие задачи нужно сделать в следующем релизе. его задача и ответственность — контролировать успешный прогресс и выполнение проекта. Если тут есть PMы — поправляйте, дополняйте.
А во-вторых, PM — это другой человек, а я по-видимому отвечаю за организацию процессов, архитектуру и лезу в код , когда есть возможночть
)
