Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 58
Цитата Ларри доставила, она звучит красиво. Но на деле, даже в гугле менеджеры проектов очень часто не технические специалисты или с ограниченными техническими познаниями. Зато они знают слова скрам, дедлайн, естимейт, умеют рисовать красивые таблички в спредшитах, писать много писем и проводить 10 митингов каждый день. Так же они любят звать на митинги инженеров, которых митинг вообще не касается и на каждом планинге задавать одни и те же вопросы по проекту, который они менелджат, но не знают и не могут понять как он работает.
Видимо, вторая часть цитаты: «но куда же мы без менеджеров».
Я читал на хабре про гугл, не помню к о чем речь шла, но суть такова: Ларри Пейдж говорил, что поначалу они хотели обойтись без менеджеров, но очень скоро пришло понимание, что разработчики тратят много времени «не туда», ибо сваливается множество организационных вопросов и прочего.
Ну если команда небольшая и у вас вот только такие проактивные люди, которые заинтересованы в росте Вашей компании, то поначалу такое и прокатит. Думаю это пройдет, если ваше дело перенесет бурный рост и разработчиков уже будет не хватать, и придется нанимать других разработчиков.
Я считаю, что наша главная особенность – качество нанимаемых нами инженеров. Главное их свойство в способности быть проактивным. Люди, работающие с нами, сами себе предприниматели – им не нужен человек, который постоянно проверяет, работают ли они.
Ну если команда небольшая и у вас вот только такие проактивные люди, которые заинтересованы в росте Вашей компании, то поначалу такое и прокатит. Думаю это пройдет, если ваше дело перенесет бурный рост и разработчиков уже будет не хватать, и придется нанимать других разработчиков.
Какой бред. Действовать по принципу «так не получилось, значит наоборот — получится» означает лишь то, что вы вначале не подумали, а сразу стали делать. И уж тем более не надо советовать людям делать так же. В итоге пришли-то к таким баянным результатам, которые описывал каждый второй владелец бизнеса в IT.
Как-то слишком утопично. Явно не для наших компаний и не для наших заказчиков. Может быть в небольших стартапах и будет работать, когда сам себе придумываешь работу, понимаешь, что от тебя зависит все, когда действительно ты — часть бизнеса.
Вообще-то ты — всегда часть бизнеса. Даже если пол моешь в офисе трансконтинентальной корпорации. Разумеется, глупо предполагать, что в этой стране так может стать в одночасье. Однако люди новой формации, скажем, молодые ай-ти специалисты, которые только выходят на рынок, вполне себе могут начать жить именно так.
А что за приложение класса SAAS использует команда автора?
А какими продуктами и успехами известны герои статьи?
4 рабочих дня в неделю это хорошая идея кстати. Надо всерьез об этом подумать.
Дополнительные 28 дней отпуска к основным 28 выгоднее для компании, да и для работника наверняка тоже. Лично я уже на второй день выходных начинаю маяться дурью, а вот от отпуска бы не отказался.
А можно сделать выходным среду. Тогда 2 дня работаешь, 1 день отдыхаешь, 2 — работаешь, 2 — отдыхаешь.
Отличное получится решение со средой из старого анегдота :)
Руководитель собрал коллектив в понедельник на летучку.
«Ну что, сегодня понедельник, надо отдохнуть от выходных, а во вторник надо уже втягиваться в работу. В среду придется поработать, а в четверг надо готовиться к выходным, ну а в пятницу короткий день. Вопросы есть?»
«Есть, а когда эта фигня со средой закончится?»
Руководитель собрал коллектив в понедельник на летучку.
«Ну что, сегодня понедельник, надо отдохнуть от выходных, а во вторник надо уже втягиваться в работу. В среду придется поработать, а в четверг надо готовиться к выходным, ну а в пятницу короткий день. Вопросы есть?»
«Есть, а когда эта фигня со средой закончится?»
Мне больше импонирует идея короткого рабочего дня. 6 часов вполне достаточно.
А мне понравилась такая система. Если я правильно понял, у них есть что-то вроде баг-треккера, куда каждый ставит задачи типа «Надо сделать такую-то менюшку», или «Надо реализовать либу для такой-то задачи», или «Отваливается то-то и то-то при попытке сделать это». А потом кто-нибудь из разрабов САМ берет себе задачу на основании своих навыков и желаний, и работает над ней. Мне кажется, это восхитительно. Получается, что если у кого-то есть опыт и желание заниматься GUI, он занимается им, у кого-то графикой — занимается графикой, у кого чем-то низкоуровневым — занимается этим. По-моему, именно это и даёт такой прирост производительности.
Agile же!
Не все задачи, особенно после выката проекта в продакшн, будут находить своих героев)
Если команда хоть немного настроена на результат, то даже не самые интересные задачи будут кем-то решены. Но это только моё мнение.
Обязательно. Когда-нибудь, когда закончатся интересные задачи на созидание, а не на фикс плавающего бага.
Все-таки распределение тасков по принципу «взял, что понравилось», на мой взгляд, не совсем жизнеспособно. Скорее всего что-то автор недоговаривает.
Все-таки распределение тасков по принципу «взял, что понравилось», на мой взгляд, не совсем жизнеспособно. Скорее всего что-то автор недоговаривает.
Автор, скорее всего, недоговаривает то что такая методика ориентирована на относительно узкий класс задач и наверняка не подойдет для разработки сложных бизнес-приложений со множеством ролей, процессов, интерфейсов, интеграций, отчетов и т.п.
Для поисковика не знаю — может и подойдет.
Для поисковика не знаю — может и подойдет.
Исправление плавающего бага (гейзенбага) это тоже созидание. Ведь никто из пользователей просто не увидит новую функциональность если проект работает нестабильно. Да и как показывает практика гейзенбаги не возникают на ровном месте, а возникают лишь в местах либо недоделок (не до конца решённых задач), а таких, по идее, при указанной схеме работы не должно быть. Либо возникают из-за не очень хорошей архитектуры, когда наращивание функциональности не обходится без костылей, но при указанной схеме проще и полезнее на перспективу допилить архитектуру, нежели по-быстрому выкатить новую функциональность.
Все таки понимание целей проекта ортогонально скиллам менеджера (технические/не технические).
Вопрос в выдержке, силе воли, желанию в конце концов вывести проект в продакшн. Точно так же и обычные менеджеры могу запороть проект.
Вопрос в выдержке, силе воли, желанию в конце концов вывести проект в продакшн. Точно так же и обычные менеджеры могу запороть проект.
Но… но я же существую! :cry:
Много лет работал удаленно и, как потом оказалось, куда более продуктивно чем в офисе.
В офисе много отвлекалок. Постоянные бла-бла, приколы и т.п. Это хоть и неплохо, но порой слишком сильно убивает производительность. По сути из 5 рабочих дней почти день уходит на бла-бла. + 2 часа на дорогу в день тоже не мотивируют. Но хотябы жопу от стула отдираю =)
Удаленно работал в команде программистов, где был ПМ. Он, кроме программирования занимался общением с заказчиками и выставлением/назначением задач. Часто единственный от него вопрос был «есть вопросы по задаче?». Дальше никто никого без необходимости не трогает до конца дня. Контроль был вида: успел за отведенное время — молодец, лови еще задачу, а если не успел — объясни в кратце что случилось и сколько еще нужно времени. Претензий ни разу небыло если завалил сроки, а объяснения скорее помогали понять где мы не досчитали сложность задачи. Оценку времени проводили всей толпой 1 раз за спринт (1-2 недели) и чаще всего времени было с небольшим запасом. Это работало очень эффективно. Но нас было 6 человек всего. Не думаю что такой вариант прокатит если в комадне более 10 человек.
Много лет работал удаленно и, как потом оказалось, куда более продуктивно чем в офисе.
В офисе много отвлекалок. Постоянные бла-бла, приколы и т.п. Это хоть и неплохо, но порой слишком сильно убивает производительность. По сути из 5 рабочих дней почти день уходит на бла-бла. + 2 часа на дорогу в день тоже не мотивируют. Но хотябы жопу от стула отдираю =)
Удаленно работал в команде программистов, где был ПМ. Он, кроме программирования занимался общением с заказчиками и выставлением/назначением задач. Часто единственный от него вопрос был «есть вопросы по задаче?». Дальше никто никого без необходимости не трогает до конца дня. Контроль был вида: успел за отведенное время — молодец, лови еще задачу, а если не успел — объясни в кратце что случилось и сколько еще нужно времени. Претензий ни разу небыло если завалил сроки, а объяснения скорее помогали понять где мы не досчитали сложность задачи. Оценку времени проводили всей толпой 1 раз за спринт (1-2 недели) и чаще всего времени было с небольшим запасом. Это работало очень эффективно. Но нас было 6 человек всего. Не думаю что такой вариант прокатит если в комадне более 10 человек.
Я так и не понял, как они ведут задачи? Кто план то рисует что делать, а если нужно взаимодействие между N-инженерами, которые типа сами знаю, что им делать… что угодно, но не твою задачу? Короче самый главную проблему, где как раз и нужен начальник/координатор, обошли стороной.
Автор просто троллит менеджеров и продукт owner'ов
Типа, он не понимает зачем они нужны.
Во-первых, они поисковик пилят. У поисковика специфический набор требований.
Там продукт owner особо и не нужен.
Ашманов в курсе ;0)
А роль менеджера снижена набором программистов-предпринимателей (я так понимаю они в доле). Т.е. там управление не надо менеджеру делегировать.
Хе-хе, если бы каждая контора где я работал брала меня в долю…
Типа, он не понимает зачем они нужны.
Во-первых, они поисковик пилят. У поисковика специфический набор требований.
Там продукт owner особо и не нужен.
Ашманов в курсе ;0)
А роль менеджера снижена набором программистов-предпринимателей (я так понимаю они в доле). Т.е. там управление не надо менеджеру делегировать.
Хе-хе, если бы каждая контора где я работал брала меня в долю…
Хе-хе, если бы каждая контора где я работал брала меня в долю…
Однажды я предложил руководству компании принять некий регламент, согласно которому человек, придумавший приносящую прибыль услугу, получал бы процент с прибыли от нее. Руководство покивало головой, но так ничего и не сделало.
Еще один мой коллега прямо заявил, что он знает способ усовершенствовать нашу систему, который бы принес миллионы рублей прибыли. Но он готов им поделиться только за процент. Ему отказали.
Вообщем, наши компании не хотят делиться с программистами. Мы всего лишь наемные работники.
«и кроме того, проверяют, как именно они это делают»
Не хочу пользоваться программами/системами/машинами, которые неизвестно как сделаны и которые никто не проверял.
Не хочу пользоваться программами/системами/машинами, которые неизвестно как сделаны и которые никто не проверял.
Проблема здесь в стереотипе, что менеджер — это начальник. Даже цитата Ларри Пейджа здесь подтверждает: многие разработчики просто не могут понять, что в правильной системе управления менеджер может делать много полезной организационной работы и освободить их мозги для интересного и продуктивного программирования, при этом не имея никакого права ничего указывать.
В любом современном agile, да и в больших методологиях (не только методологиях разработки ПО — вообще в подходах к управлению), единственный настоящий стереотипный начальник — это клиент.
В любом современном agile, да и в больших методологиях (не только методологиях разработки ПО — вообще в подходах к управлению), единственный настоящий стереотипный начальник — это клиент.
в правильной системе управления менеджер может делать много полезной организационной работы и освободить их мозги для интересного и продуктивного программирования
Точно. Об этом ещё неплохо написано в Peopleware.
Эх, была бы в конце статьи еще и кнопка как на хедхантере «Хочу здесь работать!».
Вакансии на их сайте находятся без труда:
qz.com/about/hiring
qz.com/about/hiring
Хочу у вас работать!
В принципе позиция этих ребят понятна — они собирают лучших людей, проактивных, самомотивирующихся, любящих и хотящих работать, даюти этим людям хорошие условия, минимум ограничений и контроля и получают отличный результат. Это прекрасно и радует что у них получилось.
К сожалению такого рода людей не хватит чтобы покрыть все потребности в айти услугах в мире, поэтому нужно как-то использовать так же и труд ленивых, глупых, немотивированных, пассивных и прочих людей с разными недостатками, у которых КПД значительно ниже, а значит и стоимость их содержания нужно как-то понижать, чтобы иметь прибыль. И тут на арену выходят методологии, менеджеры, контроль и прочая известная всем корпоративная культура.
Хорошо иметь трёх офигительных программистов. Но когда их нет — приходится за те же деньги брать 10 таких себе программистов, менеджера, тим-лида и тестировщика. И это реально работает!
К сожалению такого рода людей не хватит чтобы покрыть все потребности в айти услугах в мире, поэтому нужно как-то использовать так же и труд ленивых, глупых, немотивированных, пассивных и прочих людей с разными недостатками, у которых КПД значительно ниже, а значит и стоимость их содержания нужно как-то понижать, чтобы иметь прибыль. И тут на арену выходят методологии, менеджеры, контроль и прочая известная всем корпоративная культура.
Хорошо иметь трёх офигительных программистов. Но когда их нет — приходится за те же деньги брать 10 таких себе программистов, менеджера, тим-лида и тестировщика. И это реально работает!
Это реально работает пока задача — автоматизировать бизнес-процессы
или сайты клепать для цветочных ларьков.
Наберите хоть 100 000 быдлокодеров с обвязкой из тимлидов
и тестировщиков — они вам движок гугла не родят,
так же, как 100 макак не напишут Войну и Мир,
хоть целый год будут барабанить по печатным машинкам.
Для определенного уровня задач подходят только суперзвезды.
или сайты клепать для цветочных ларьков.
Наберите хоть 100 000 быдлокодеров с обвязкой из тимлидов
и тестировщиков — они вам движок гугла не родят,
так же, как 100 макак не напишут Войну и Мир,
хоть целый год будут барабанить по печатным машинкам.
Для определенного уровня задач подходят только суперзвезды.
Вы же сами себе и отвечаете. Для определённого уровня задач суперзвёзды не годятся — они воротят нос и говорят, что не нанимались делать грязную работу.
Если уж мы говорим об отрасли вообще, то да, кому-то надо делать и сайты для цветочных ларьков, пока цветочным ларькам нужны сайты и они готовы платить за них свою тысячу долларов.
Если уж мы говорим об отрасли вообще, то да, кому-то надо делать и сайты для цветочных ларьков, пока цветочным ларькам нужны сайты и они готовы платить за них свою тысячу долларов.
Это спорное утверждение. Звезда нужна для открытия. Леонардо Да Винчи придумал вертолёт, но есть ли гении уровня Леонардо на современных авиазаводах? И нужны ли они там?
Придумать движок гугла — это изобретение, тут нужна светлая голова. А накодить софта для работы тысяч серверов по всему миру, с разными обвязками и условиями — это уже не изобраетение, это рутинная работа. И она вполне по силе тысяче посредственностей под управлением.
Сравнение с макаками некорректно. Ребята из статьи собирают людей лучших во всём. Я говорю что можно брать людей с недостатками, например ленивых, или необязательных, или глупых и вместе при правильном построении команды они будут заменять одного уберменша. За счёт компенсации недостатков друг друга, организации, контроля. И это необходимо делать, потому что работы в мире много, а идеальных людей на всю её не хватает.
Придумать движок гугла — это изобретение, тут нужна светлая голова. А накодить софта для работы тысяч серверов по всему миру, с разными обвязками и условиями — это уже не изобраетение, это рутинная работа. И она вполне по силе тысяче посредственностей под управлением.
Сравнение с макаками некорректно. Ребята из статьи собирают людей лучших во всём. Я говорю что можно брать людей с недостатками, например ленивых, или необязательных, или глупых и вместе при правильном построении команды они будут заменять одного уберменша. За счёт компенсации недостатков друг друга, организации, контроля. И это необходимо делать, потому что работы в мире много, а идеальных людей на всю её не хватает.
> А накодить софта для работы тысяч серверов по всему миру, с разными обвязками и условиями — это уже не изобраетение, это рутинная работа. И она вполне по силе тысяче посредственностей под управлением.
Это вы немного поторопились. Там столько заморочек, что без, как минимум, грамотного архитектора и нескольких хороших разработчиков ничего не сделать.
Придумать гениальную идею и реализовать её «в железе» — задачи хоть и разные, но требующие хороших спецов в любом случае.
Это вы немного поторопились. Там столько заморочек, что без, как минимум, грамотного архитектора и нескольких хороших разработчиков ничего не сделать.
Придумать гениальную идею и реализовать её «в железе» — задачи хоть и разные, но требующие хороших спецов в любом случае.
А по какому принципу у вас начисляется зарплата?
Как именно там программисты всё-таки общаются? Через iAutonomous? Я надеюсь, там есть функция «просто сказать тому-то то-то»?
Интересно кто увольнял неправильных программистов или кто решал что нужно нанять новых.
С задачами понятно. А как решаются более глобальные задачи, например, как они обсуждают/утверждают архитектуру фронтенда или бакенда не важно?
Очень круто! Немного завидую…
Удачи:-)
Удачи:-)
Я считаю, что наша главная особенность – качество нанимаемых нами инженеров.
Так с менеджерами то же самое.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Почему у нас нет боссов и офиса, и почему мы работаем 4 дня в неделю