gitlab, как я уже упоминал выше, мне видится наиболее перспективным сейчас. Ребята большие молодцы, хорошо развивают свой проект.
В то же время, тогда когда мы его пробовали ранее, продукт был сильно сырым.
Когда мы только начали делать инструмент, сторонние инструменты были другие, да. И с тех пор немало эволюционировали.
А битбакет разве поддерживает self-hosted установку? Гитхаб может, но стоит очень уж дорого.
Не совсем. Бранчдифф это почти то же самое что пулл реквест. Но без необходимости создания отдельной сущности. И более динамичный.
Простой пример — в коде ошибка. Идеология пулл-реквестов во-первых откладывает ее обнаружение на более поздний срок. На момент, когда девелопер оформит пулл-реквест и по нему начнутся автоматические проверки (например). А во-вторых, чтобы ошибку исправить надо пулл реквест отменить и создать новый. Это лишнее время.
В случае с бранчдиффами этого ничего не нужно. Для простоты можно считать что бранчдифф это пулл-реквест, но без лишней бюрократии :)
Ну почему же, такой подход может существовать. Но если взять в уравнение скорость, необходимость аккуратного внедрения в текущий процесс, на текущих задачах, учесть размер компании и ее рост, то все становится не так очевидно. Можно заставить 250 инженеров «правильно» оформлять коммиты перед пушем, но зачем? Какая бизнесу от этого польза?
Хороший вопрос. У меня есть отдельная статья про «правильное» ревью и «неправильное» ревью, где я описываю распространённые ошибки. Скоро опубликуем и подискутируем там в комментариях.
Спасибо!
Компании не нужен «мальчик для битья». Хорошей компании, конечно, ведь случаи разные бывают.
От наказания особой пользы нет. Нужно чтобы чел решал задачи компании. Отсюда и формируется список обязанностей. У кого-то он может быть сильно формальным и расписанным от и до. У кого-то более-менее размытый.
А ответственность должна вознаграждаться соответственно, иначе ее мало кто на себя согласится взять. Но все измерять деньгами конечно же не нужно. Деньги — слабый и краткосрочный мотиватор. Факторов в уравнении сильно больше.
Тимлид (как и другие управленцы) ответственность на себя берет сам, ему ее не «спихивают». А вот как он дальше эту ответственность реализует, как раз и отличает условного тимлида от условного топ-менеджера.
Due date разработчик выдает не в одно лицо, а как минимум, посоветовавшись с менеджером/техническим лидом. Научить все-таки пытаемся, но бывает всякое. Если совсем не получается — признаем что конкретный человек в фичевую разработку не подходит и расстаемся с ним. Это не обязательно означает увольнение. Может быть переход в нефичевую команду, например.
Это просто разработчик в команде. Уровень может быть разный и мы даем «порулить» фичей новичкам в том числе. Под присмотром более опытных, разумеется — для того, чтобы более слабые набирались опыта.
Обучаем/находим — зависит от. Чаще очень трудно найти полностью готового специалиста по абсолютно всем параметрам, поэтому обычно найм — это компромисс. И мы даем время человеку на то, чтобы он подтянул свои навыки после. Бывает так, что отличный разработчик, который не может менеджить задачи, уходит. Нам не нужны «кодеры», нам нужны взрослые, думающие программисты.
Микропроджектменеджер пишет сам код, да. Пропорция менеджмента/программирования зависит от многих факторов: опыт, «чутье», размер фичи и т.д.
Т.е. Володя все-таки должен общаться с продакт-менеджером, дизайнерами, бухгалтерами
Угу. Если Родина требует, то куда деваться?
Я вот читаю, что у меня и у технического менеджера должно быть много свободного времени.
А я считаю что я не должен ходить на работу. Но иногда все-таки нужно, верно?
Видели бы вы тоску в его глазах, когда я очередной раз появляюсь на пороге…
Видел, и много раз. Но есть «хочу», а есть «нужно».
какую помощь он может дать? Дать людей?
Очень сильно зависит от. Увеличить людей — самый простой способ. Утверждаю что есть еще масса вещей, которые стоит попробовать. Главное — результат. А как каждый конкретный Володя его добьется — дело десятое. За это мы Володь и ценим.
Нет, вообще не понятна суть. Я не могу на стороне.
И это прекрасно. Значит у вас нет иного выхода, кроме как «задолбать» своего дизайнера, чтобы он сделал как надо. В этом и суть. У нас нет задачи сделать вам комфортно (уж извините, при всем уважении). У нас задача — дать результат. Следовательно мы пушим всех, и вас в том числе (в данном примере), действовать на результат, выводя вас из зоны комфорта.
Ну смотрите, Андрей.
С точки зрения дат, ситуация Васи и Пети не отличается ничем. А вот с точки зрения ответственности, отличается. В чем преимущество Васи? В том, что он — «пушер». Он «драйвер» и двигатель всех процессов. Может ли он что-то требовать? Может, если это ему поможет сделать задачу эффективнее. Он может просить, убеждать, требовать, взывать к помощи менеджера — не важно.
Если задачу во время не сделал Петя, то ничего страшного. Ну не сделал, и не сделал. А вот для Васи любой исход означает вопрос: «как сделать быстрее»? Его не оштрафуют. Но его обязательно спросят, как быть быстрее в следующий раз.
Про пример с гайдлайнами и вопросом кто будет рисовать — это неважно. Пушить процесс будет Вася. Если он нарисует лучше чем дизайнер, то хорошо. Но скорее всего, дизайнет нарисует лучше. А вот прийти к дизайнеру и направить его на путь истинный должен Вася. Если он прийдет к дизайнеру и тому некогда, то Вася может заказать дизайн на стороне (я сейчас совсем-совсем утрирую, но надеюсь, суть понятна).
Не важно кто и что делает, у кого хватает ресурсов и у кого есть желание что-то делать. Главное — результат. И для его достижения нужна какая-то цель. Такой «универсальной целью» во многих ситуациях и выступает Due date.
Да, так яснее, спасибо.
Я так и ожидал, что будет ответ вроде «по-разному бывает». Это нормально, именно для того мы правила задаем и процессы создаем, чтобы в коллективе могли работать и приносить пользу компании практически все. И понимающие и не понимающие. И согласные и не согласные.
И здорово, если в компании все разработчики толковые и понимающие. Но что если не все? Или как вновь прибывших внедрять и воспитывать правильно?
Многие из моих утверждений в статье спорные. Это сделано намеренно, чтобы читатель задумался, задал себе вопрос «какого фига?». А может и в комментариях со мной подискутировал :)
Ну почему же расходятся? Я тоже считаю что обстановка очень важна. Но как ее формализовать? Хорошо если вы прийдя в компанию и поработав там, поймете хорошо там с этой самой обстановкой или нет. А если плохо? Уходить в другую компанию?
В статье я намеренно упоминаю инженерную культуру, в это широкое понятие входит и обстановка тоже. Когда работаешь в окружении крутых ребят, чувствуешь себя мотивированным делать крутые вещи.
И частью своей работы и работы других менеджеров считаю как раз воспитание инженерной культуры и взращивание той самой обстановки, в которой людям драйвово работать. Процессы — один из механизмов, позволяющих эту самую культуру развивать.
Если вы обратили внимание, я даже сделал оговорку о том, что я намеренно утрирую и «сгущаю краски» при приведении примеров. Reductio ad absurdum — это специальный полемический прием, позволяющий наиболее красочно показать те или иные аспекты обсуждаемой проблемы.
Разумеется у разных людей цели разные. И я очень рад, что есть ребята, которых просто драйвит делать крутые вещи. Это прикольно и здорово мотивирует. Моя же цель в том, чтобы сделать процесс, работающий в большинстве случаев. Даже тогда, когда у людей внутренней мотивации не вполне достаточно.
Привет, Александр!
Пойдем по пунктам.
1) Как быть, если «Фича нужна бизнесу в продакшне раньше чем due date?». Due date это в первую очередь бизнесовый показатель. Если фича нужна раньше, чем Due date, это значит что Due date = раньше :). Понятно что бывает так, что бизнес требует почти невозможного. Но если задуматься, то все что мы делаем, нужно в первую очередь именно бизнесу. И если получилось так, что мы должны к определенному сроку дать какой-то продукт, то надо выложиться по полной, но сделать. Мы нередко делаем MVP-продукт. Это когда мы компромиссным путем в кратчайшие сроки даем на выход результат, который позволяет прощупать концепт. И если он «летит», то полируем фичу дальше.
2) Во-первых, надо регулярно с менеджером проверять результат на промежуточных этапах, а во-вторых, если мы делаем прагматично и полезно бизнесу, то это не всегда означает что мы делаем плохо, верно? Может быть оно с архитектурной точки зрения не всегда оптимально, но нашим пользователям зачастую наплевать как оно сделано изнутри. Если фича сделана так, что ее можно «продать» пользователю, значит она сделана «на отлично». При этом мы сразу делаем оговорку, что возможно в будущем надо будет делать рефакторинг, или даже полную переделку — это все технический долг.
3) По поводу коллективной ответственности, и «устаревшего правила» — я даже рад что бывают альтернативные мнения. С другой стороны, есть зарекомендовавший себя подход и правила, а есть мода. И если автомат Калашникова работает, несмотря на то что он «устарел», может это значит что он не так уж и плохо сделан?
В то же время, тогда когда мы его пробовали ранее, продукт был сильно сырым.
Ах да, атлассиан. Уже вижу с каким скрипом это будет у нас работать. И лицензия на 500 пользователей под 20к стоит.
За ссылку спасибо.
Когда мы только начали делать инструмент, сторонние инструменты были другие, да. И с тех пор немало эволюционировали.
А битбакет разве поддерживает self-hosted установку? Гитхаб может, но стоит очень уж дорого.
Не совсем. Бранчдифф это почти то же самое что пулл реквест. Но без необходимости создания отдельной сущности. И более динамичный.
Простой пример — в коде ошибка. Идеология пулл-реквестов во-первых откладывает ее обнаружение на более поздний срок. На момент, когда девелопер оформит пулл-реквест и по нему начнутся автоматические проверки (например). А во-вторых, чтобы ошибку исправить надо пулл реквест отменить и создать новый. Это лишнее время.
В случае с бранчдиффами этого ничего не нужно. Для простоты можно считать что бранчдифф это пулл-реквест, но без лишней бюрократии :)
Ну почему же, такой подход может существовать. Но если взять в уравнение скорость, необходимость аккуратного внедрения в текущий процесс, на текущих задачах, учесть размер компании и ее рост, то все становится не так очевидно. Можно заставить 250 инженеров «правильно» оформлять коммиты перед пушем, но зачем? Какая бизнесу от этого польза?
Хороший вопрос. У меня есть отдельная статья про «правильное» ревью и «неправильное» ревью, где я описываю распространённые ошибки. Скоро опубликуем и подискутируем там в комментариях.
Спасибо!
От наказания особой пользы нет. Нужно чтобы чел решал задачи компании. Отсюда и формируется список обязанностей. У кого-то он может быть сильно формальным и расписанным от и до. У кого-то более-менее размытый.
А ответственность должна вознаграждаться соответственно, иначе ее мало кто на себя согласится взять. Но все измерять деньгами конечно же не нужно. Деньги — слабый и краткосрочный мотиватор. Факторов в уравнении сильно больше.
Обучаем/находим — зависит от. Чаще очень трудно найти полностью готового специалиста по абсолютно всем параметрам, поэтому обычно найм — это компромисс. И мы даем время человеку на то, чтобы он подтянул свои навыки после. Бывает так, что отличный разработчик, который не может менеджить задачи, уходит. Нам не нужны «кодеры», нам нужны взрослые, думающие программисты.
Микропроджектменеджер пишет сам код, да. Пропорция менеджмента/программирования зависит от многих факторов: опыт, «чутье», размер фичи и т.д.
Угу. Если Родина требует, то куда деваться?
А я считаю что я не должен ходить на работу. Но иногда все-таки нужно, верно?
Видел, и много раз. Но есть «хочу», а есть «нужно».
Очень сильно зависит от. Увеличить людей — самый простой способ. Утверждаю что есть еще масса вещей, которые стоит попробовать. Главное — результат. А как каждый конкретный Володя его добьется — дело десятое. За это мы Володь и ценим.
И это прекрасно. Значит у вас нет иного выхода, кроме как «задолбать» своего дизайнера, чтобы он сделал как надо. В этом и суть. У нас нет задачи сделать вам комфортно (уж извините, при всем уважении). У нас задача — дать результат. Следовательно мы пушим всех, и вас в том числе (в данном примере), действовать на результат, выводя вас из зоны комфорта.
С точки зрения дат, ситуация Васи и Пети не отличается ничем. А вот с точки зрения ответственности, отличается. В чем преимущество Васи? В том, что он — «пушер». Он «драйвер» и двигатель всех процессов. Может ли он что-то требовать? Может, если это ему поможет сделать задачу эффективнее. Он может просить, убеждать, требовать, взывать к помощи менеджера — не важно.
Если задачу во время не сделал Петя, то ничего страшного. Ну не сделал, и не сделал. А вот для Васи любой исход означает вопрос: «как сделать быстрее»? Его не оштрафуют. Но его обязательно спросят, как быть быстрее в следующий раз.
Про пример с гайдлайнами и вопросом кто будет рисовать — это неважно. Пушить процесс будет Вася. Если он нарисует лучше чем дизайнер, то хорошо. Но скорее всего, дизайнет нарисует лучше. А вот прийти к дизайнеру и направить его на путь истинный должен Вася. Если он прийдет к дизайнеру и тому некогда, то Вася может заказать дизайн на стороне (я сейчас совсем-совсем утрирую, но надеюсь, суть понятна).
Не важно кто и что делает, у кого хватает ресурсов и у кого есть желание что-то делать. Главное — результат. И для его достижения нужна какая-то цель. Такой «универсальной целью» во многих ситуациях и выступает Due date.
Удачи!
Я так и ожидал, что будет ответ вроде «по-разному бывает». Это нормально, именно для того мы правила задаем и процессы создаем, чтобы в коллективе могли работать и приносить пользу компании практически все. И понимающие и не понимающие. И согласные и не согласные.
И здорово, если в компании все разработчики толковые и понимающие. Но что если не все? Или как вновь прибывших внедрять и воспитывать правильно?
Многие из моих утверждений в статье спорные. Это сделано намеренно, чтобы читатель задумался, задал себе вопрос «какого фига?». А может и в комментариях со мной подискутировал :)
В статье я намеренно упоминаю инженерную культуру, в это широкое понятие входит и обстановка тоже. Когда работаешь в окружении крутых ребят, чувствуешь себя мотивированным делать крутые вещи.
И частью своей работы и работы других менеджеров считаю как раз воспитание инженерной культуры и взращивание той самой обстановки, в которой людям драйвово работать. Процессы — один из механизмов, позволяющих эту самую культуру развивать.
Спасибо за ваш комментарий.
В нашей компании разработчики очень толковые. А в вашей?
Если вы обратили внимание, я даже сделал оговорку о том, что я намеренно утрирую и «сгущаю краски» при приведении примеров. Reductio ad absurdum — это специальный полемический прием, позволяющий наиболее красочно показать те или иные аспекты обсуждаемой проблемы.
Разумеется у разных людей цели разные. И я очень рад, что есть ребята, которых просто драйвит делать крутые вещи. Это прикольно и здорово мотивирует. Моя же цель в том, чтобы сделать процесс, работающий в большинстве случаев. Даже тогда, когда у людей внутренней мотивации не вполне достаточно.
Удачи!
Пойдем по пунктам.
1) Как быть, если «Фича нужна бизнесу в продакшне раньше чем due date?». Due date это в первую очередь бизнесовый показатель. Если фича нужна раньше, чем Due date, это значит что Due date = раньше :). Понятно что бывает так, что бизнес требует почти невозможного. Но если задуматься, то все что мы делаем, нужно в первую очередь именно бизнесу. И если получилось так, что мы должны к определенному сроку дать какой-то продукт, то надо выложиться по полной, но сделать. Мы нередко делаем MVP-продукт. Это когда мы компромиссным путем в кратчайшие сроки даем на выход результат, который позволяет прощупать концепт. И если он «летит», то полируем фичу дальше.
2) Во-первых, надо регулярно с менеджером проверять результат на промежуточных этапах, а во-вторых, если мы делаем прагматично и полезно бизнесу, то это не всегда означает что мы делаем плохо, верно? Может быть оно с архитектурной точки зрения не всегда оптимально, но нашим пользователям зачастую наплевать как оно сделано изнутри. Если фича сделана так, что ее можно «продать» пользователю, значит она сделана «на отлично». При этом мы сразу делаем оговорку, что возможно в будущем надо будет делать рефакторинг, или даже полную переделку — это все технический долг.
3) По поводу коллективной ответственности, и «устаревшего правила» — я даже рад что бывают альтернативные мнения. С другой стороны, есть зарекомендовавший себя подход и правила, а есть мода. И если автомат Калашникова работает, несмотря на то что он «устарел», может это значит что он не так уж и плохо сделан?
Спасибо за ваше мнение!