Сообщение Re: Вопросы к тим лидам от 01.02.2017 13:26
Изменено 01.02.2017 13:31 greenpci
Re: Вопросы к тим лидам
Твой вопрос дает информацию о культуре конторы, людях и о тебе. Есть несколько сигналов, которые я распознал:
Внутреннее качество технических решений занимает последнее место после финансовых показателей и отношений в коллективе. Показателен отказ использовать open-source решения и отказ от разделения труда. Ты же, наоборот, инженер и технический специалист.
Буду отвечать ниже исходя из этого:
Здравствуйте, licedey, Вы писали:
L>
1. Отслеживать прогресс
2. Знать и быстро отвечать, кто и чем занимается в данный момент
3. Знать о дедлайнах, что нужно завершить для их выполнения и напоминать об этом членам команды.
4. Распознать сильные стороны членов команды и кому, что лучше поручить.
5. Так же, иметь представление об амбициях и обидах ("а почему мне не дали?!") и распределять задачи вызывая минимум истерик.
6. Знать на высоком уровне детали проблем, которые решает команда и участвовать в разговоре.
7. Арбитраж и суд, чье решение или предложение выберем.
8. Хвалить команду и отдельных ее членов, чтобы всем было приятно и никто не завидовал.
9. Напоминать о timesheets, КПА и прочей бюроктатии и уметь писать простыни самому. "Что хорошего можете написать о работе Махмуда за 2016 год?"
10. Быть позитивным, стричься, бриться, аккуратно одеваться и излучать успех.
L>В чем отличие тим лида от архитектора или PM'a?. Разве лид не должен решать архитектурные вопросы? Разве не должен создавать распределять таски?
ПМ не знает тех. деталей, а Тим Лид должен разбираться и в технических вещах и в пользовательском домене. ПМ отслеживает и напоминает, Тим Лид делает тоже самое, но еще и принимает решения.
L>
В заграницах Старший Разраб это самая низкая должность. Джуниоров, обычно, быстро повышают или они сами уходят на повышение в другую контору.
L>3. Как по науке распределять задачи между мидлами и сеньорами? На интервью я сказал, что нужно выделить часть проекта, за которую человек отвечает, максимально независимую от остальных, и пусть совершенствует свою песочницу общаясь с другими через интерфейсы. Это решение похоже на идеального коня в вакууме, и PM неодобрительно покачал головой. Но а как правильно?
Ты сказал правильно с точки зрения технаря. Для них же, распределение труда это смертный грех. Они хотят заменяемость и ротации. Никто не будет смотреть на качество кода, а если баги, то заказчики позвонят в суппорт и потепят. Убытков, скорее всего от этого не будет. Подыграй им, и в следующий раз следуй аджайлу и скраму. Только фул стек, учимся на ходу, дольше месяца на одном модуле не сидим, книжки не читаем, стек оверфлоу и вперед. Ротации, ротации. Так победим!
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>Хотелось понять как не завернуть проект в сторону, что хочет заказчик — так и пляшем. Неважно будет уже, и архитектура и покрытие тестами и в целом качество, главное успеть его удовлетворить. В корне не хотелось бы такого, иначе работа будет ад и я уйду опять в свою берлогу фрилансить.
Именно так и будет. Не будь перфекционистом.
Внутреннее качество технических решений занимает последнее место после финансовых показателей и отношений в коллективе. Показателен отказ использовать 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.
Tyler Durden "Fight Club"
Re: Вопросы к тим лидам
Твой вопрос дает информацию о культуре конторы, людях и о тебе. Есть несколько сигналов, которые я распознал:
Внутреннее качество технических решений занимает последнее место после финансовых показателей и отношений в коллективе. Показателен отказ использовать 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>
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>Хотелось понять как не завернуть проект в сторону, что хочет заказчик — так и пляшем. Неважно будет уже, и архитектура и покрытие тестами и в целом качество, главное успеть его удовлетворить. В корне не хотелось бы такого, иначе работа будет ад и я уйду опять в свою берлогу фрилансить.
Именно так и будет. Не будь перфекционистом.
Внутреннее качество технических решений занимает последнее место после финансовых показателей и отношений в коллективе. Показателен отказ использовать 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.
Tyler Durden "Fight Club"
| видео | |
| https://www.youtube.com/watch?v=EP5aqAC8PPY | |