Pull to refresh

Comments 58

Цитата Ларри доставила, она звучит красиво. Но на деле, даже в гугле менеджеры проектов очень часто не технические специалисты или с ограниченными техническими познаниями. Зато они знают слова скрам, дедлайн, естимейт, умеют рисовать красивые таблички в спредшитах, писать много писем и проводить 10 митингов каждый день. Так же они любят звать на митинги инженеров, которых митинг вообще не касается и на каждом планинге задавать одни и те же вопросы по проекту, который они менелджат, но не знают и не могут понять как он работает.
Видимо, вторая часть цитаты: «но куда же мы без менеджеров».
Я читал на хабре про гугл, не помню к о чем речь шла, но суть такова: Ларри Пейдж говорил, что поначалу они хотели обойтись без менеджеров, но очень скоро пришло понимание, что разработчики тратят много времени «не туда», ибо сваливается множество организационных вопросов и прочего.
Я считаю, что наша главная особенность – качество нанимаемых нами инженеров. Главное их свойство в способности быть проактивным. Люди, работающие с нами, сами себе предприниматели – им не нужен человек, который постоянно проверяет, работают ли они.

Ну если команда небольшая и у вас вот только такие проактивные люди, которые заинтересованы в росте Вашей компании, то поначалу такое и прокатит. Думаю это пройдет, если ваше дело перенесет бурный рост и разработчиков уже будет не хватать, и придется нанимать других разработчиков.
Какой бред. Действовать по принципу «так не получилось, значит наоборот — получится» означает лишь то, что вы вначале не подумали, а сразу стали делать. И уж тем более не надо советовать людям делать так же. В итоге пришли-то к таким баянным результатам, которые описывал каждый второй владелец бизнеса в IT.
Как-то слишком утопично. Явно не для наших компаний и не для наших заказчиков. Может быть в небольших стартапах и будет работать, когда сам себе придумываешь работу, понимаешь, что от тебя зависит все, когда действительно ты — часть бизнеса.
Вообще-то ты — всегда часть бизнеса. Даже если пол моешь в офисе трансконтинентальной корпорации. Разумеется, глупо предполагать, что в этой стране так может стать в одночасье. Однако люди новой формации, скажем, молодые ай-ти специалисты, которые только выходят на рынок, вполне себе могут начать жить именно так.
А что за приложение класса SAAS использует команда автора?
>нашей внутренней разработкой, которую мы зовём iAutonomous

Я так понимаю, она и есть
А какими продуктами и успехами известны герои статьи?
UFO just landed and posted this here
4 рабочих дня в неделю это хорошая идея кстати. Надо всерьез об этом подумать.
Дополнительные 28 дней отпуска к основным 28 выгоднее для компании, да и для работника наверняка тоже. Лично я уже на второй день выходных начинаю маяться дурью, а вот от отпуска бы не отказался.
А можно сделать выходным среду. Тогда 2 дня работаешь, 1 день отдыхаешь, 2 — работаешь, 2 — отдыхаешь.
Отличное получится решение со средой из старого анегдота :)

Руководитель собрал коллектив в понедельник на летучку.
«Ну что, сегодня понедельник, надо отдохнуть от выходных, а во вторник надо уже втягиваться в работу. В среду придется поработать, а в четверг надо готовиться к выходным, ну а в пятницу короткий день. Вопросы есть?»
«Есть, а когда эта фигня со средой закончится?»
UFO just landed and posted this here
3 дня крестьянин работал, чтобы было что кушать барину, а в оставшиеся 4 дня крестьянин работал на своем участке, чтобы было что кушать ему и его семье
UFO just landed and posted this here
Мне больше импонирует идея короткого рабочего дня. 6 часов вполне достаточно.
В том или ином смысле, подобная идея выражается в таком принципе, что работа должна быть организована таким образом, чтобы программист мог 20% рабочего времени посвятить самому себе.
А мне понравилась такая система. Если я правильно понял, у них есть что-то вроде баг-треккера, куда каждый ставит задачи типа «Надо сделать такую-то менюшку», или «Надо реализовать либу для такой-то задачи», или «Отваливается то-то и то-то при попытке сделать это». А потом кто-нибудь из разрабов САМ берет себе задачу на основании своих навыков и желаний, и работает над ней. Мне кажется, это восхитительно. Получается, что если у кого-то есть опыт и желание заниматься GUI, он занимается им, у кого-то графикой — занимается графикой, у кого чем-то низкоуровневым — занимается этим. По-моему, именно это и даёт такой прирост производительности.
Agile, но за вычетом обязательного личного общения. То есть, они не отвлекаются в процессе работы, не созывают митингов.
Не все задачи, особенно после выката проекта в продакшн, будут находить своих героев)
Если команда хоть немного настроена на результат, то даже не самые интересные задачи будут кем-то решены. Но это только моё мнение.
Обязательно. Когда-нибудь, когда закончатся интересные задачи на созидание, а не на фикс плавающего бага.
Все-таки распределение тасков по принципу «взял, что понравилось», на мой взгляд, не совсем жизнеспособно. Скорее всего что-то автор недоговаривает.
Автор, скорее всего, недоговаривает то что такая методика ориентирована на относительно узкий класс задач и наверняка не подойдет для разработки сложных бизнес-приложений со множеством ролей, процессов, интерфейсов, интеграций, отчетов и т.п.
Для поисковика не знаю — может и подойдет.
Исправление плавающего бага (гейзенбага) это тоже созидание. Ведь никто из пользователей просто не увидит новую функциональность если проект работает нестабильно. Да и как показывает практика гейзенбаги не возникают на ровном месте, а возникают лишь в местах либо недоделок (не до конца решённых задач), а таких, по идее, при указанной схеме работы не должно быть. Либо возникают из-за не очень хорошей архитектуры, когда наращивание функциональности не обходится без костылей, но при указанной схеме проще и полезнее на перспективу допилить архитектуру, нежели по-быстрому выкатить новую функциональность.
UFO just landed and posted this here
UFO just landed and posted this here
Все таки понимание целей проекта ортогонально скиллам менеджера (технические/не технические).
Вопрос в выдержке, силе воли, желанию в конце концов вывести проект в продакшн. Точно так же и обычные менеджеры могу запороть проект.
Но… но я же существую! :cry:

Много лет работал удаленно и, как потом оказалось, куда более продуктивно чем в офисе.
В офисе много отвлекалок. Постоянные бла-бла, приколы и т.п. Это хоть и неплохо, но порой слишком сильно убивает производительность. По сути из 5 рабочих дней почти день уходит на бла-бла. + 2 часа на дорогу в день тоже не мотивируют. Но хотябы жопу от стула отдираю =)
Удаленно работал в команде программистов, где был ПМ. Он, кроме программирования занимался общением с заказчиками и выставлением/назначением задач. Часто единственный от него вопрос был «есть вопросы по задаче?». Дальше никто никого без необходимости не трогает до конца дня. Контроль был вида: успел за отведенное время — молодец, лови еще задачу, а если не успел — объясни в кратце что случилось и сколько еще нужно времени. Претензий ни разу небыло если завалил сроки, а объяснения скорее помогали понять где мы не досчитали сложность задачи. Оценку времени проводили всей толпой 1 раз за спринт (1-2 недели) и чаще всего времени было с небольшим запасом. Это работало очень эффективно. Но нас было 6 человек всего. Не думаю что такой вариант прокатит если в комадне более 10 человек.
Я так и не понял, как они ведут задачи? Кто план то рисует что делать, а если нужно взаимодействие между N-инженерами, которые типа сами знаю, что им делать… что угодно, но не твою задачу? Короче самый главную проблему, где как раз и нужен начальник/координатор, обошли стороной.
Автор просто троллит менеджеров и продукт owner'ов
Типа, он не понимает зачем они нужны.
Во-первых, они поисковик пилят. У поисковика специфический набор требований.
Там продукт owner особо и не нужен.
Ашманов в курсе ;0)
А роль менеджера снижена набором программистов-предпринимателей (я так понимаю они в доле). Т.е. там управление не надо менеджеру делегировать.
Хе-хе, если бы каждая контора где я работал брала меня в долю…
Хе-хе, если бы каждая контора где я работал брала меня в долю…

Однажды я предложил руководству компании принять некий регламент, согласно которому человек, придумавший приносящую прибыль услугу, получал бы процент с прибыли от нее. Руководство покивало головой, но так ничего и не сделало.
Еще один мой коллега прямо заявил, что он знает способ усовершенствовать нашу систему, который бы принес миллионы рублей прибыли. Но он готов им поделиться только за процент. Ему отказали.
Вообщем, наши компании не хотят делиться с программистами. Мы всего лишь наемные работники.
Возможно, руководство и так знает, что нужно сделать.
Знать что сделать и сделать — это не одно и то же.
«и кроме того, проверяют, как именно они это делают»

Не хочу пользоваться программами/системами/машинами, которые неизвестно как сделаны и которые никто не проверял.
То есть, вы хотите пользоваться программами/системами/машинами, код и использованные технологии которых проверены каким-то менеджером, а не программистом (знающим человеком)?
Проблема здесь в стереотипе, что менеджер — это начальник. Даже цитата Ларри Пейджа здесь подтверждает: многие разработчики просто не могут понять, что в правильной системе управления менеджер может делать много полезной организационной работы и освободить их мозги для интересного и продуктивного программирования, при этом не имея никакого права ничего указывать.
В любом современном agile, да и в больших методологиях (не только методологиях разработки ПО — вообще в подходах к управлению), единственный настоящий стереотипный начальник — это клиент.
в правильной системе управления менеджер может делать много полезной организационной работы и освободить их мозги для интересного и продуктивного программирования

Точно. Об этом ещё неплохо написано в Peopleware.
Эх, была бы в конце статьи еще и кнопка как на хедхантере «Хочу здесь работать!».
В принципе позиция этих ребят понятна — они собирают лучших людей, проактивных, самомотивирующихся, любящих и хотящих работать, даюти этим людям хорошие условия, минимум ограничений и контроля и получают отличный результат. Это прекрасно и радует что у них получилось.

К сожалению такого рода людей не хватит чтобы покрыть все потребности в айти услугах в мире, поэтому нужно как-то использовать так же и труд ленивых, глупых, немотивированных, пассивных и прочих людей с разными недостатками, у которых КПД значительно ниже, а значит и стоимость их содержания нужно как-то понижать, чтобы иметь прибыль. И тут на арену выходят методологии, менеджеры, контроль и прочая известная всем корпоративная культура.

Хорошо иметь трёх офигительных программистов. Но когда их нет — приходится за те же деньги брать 10 таких себе программистов, менеджера, тим-лида и тестировщика. И это реально работает!
Это реально работает пока задача — автоматизировать бизнес-процессы
или сайты клепать для цветочных ларьков.

Наберите хоть 100 000 быдлокодеров с обвязкой из тимлидов
и тестировщиков — они вам движок гугла не родят,
так же, как 100 макак не напишут Войну и Мир,
хоть целый год будут барабанить по печатным машинкам.

Для определенного уровня задач подходят только суперзвезды.
Вы же сами себе и отвечаете. Для определённого уровня задач суперзвёзды не годятся — они воротят нос и говорят, что не нанимались делать грязную работу.
Если уж мы говорим об отрасли вообще, то да, кому-то надо делать и сайты для цветочных ларьков, пока цветочным ларькам нужны сайты и они готовы платить за них свою тысячу долларов.
Это спорное утверждение. Звезда нужна для открытия. Леонардо Да Винчи придумал вертолёт, но есть ли гении уровня Леонардо на современных авиазаводах? И нужны ли они там?

Придумать движок гугла — это изобретение, тут нужна светлая голова. А накодить софта для работы тысяч серверов по всему миру, с разными обвязками и условиями — это уже не изобраетение, это рутинная работа. И она вполне по силе тысяче посредственностей под управлением.

Сравнение с макаками некорректно. Ребята из статьи собирают людей лучших во всём. Я говорю что можно брать людей с недостатками, например ленивых, или необязательных, или глупых и вместе при правильном построении команды они будут заменять одного уберменша. За счёт компенсации недостатков друг друга, организации, контроля. И это необходимо делать, потому что работы в мире много, а идеальных людей на всю её не хватает.
> А накодить софта для работы тысяч серверов по всему миру, с разными обвязками и условиями — это уже не изобраетение, это рутинная работа. И она вполне по силе тысяче посредственностей под управлением.

Это вы немного поторопились. Там столько заморочек, что без, как минимум, грамотного архитектора и нескольких хороших разработчиков ничего не сделать.
Придумать гениальную идею и реализовать её «в железе» — задачи хоть и разные, но требующие хороших спецов в любом случае.
Ну хоть статья и называется «почему у нас», но это перевод. Ссылка на оригинал идёт с имени автора оригинала «Cristian Rennella». Не совсем очевидно, но уж такой интерфейс на хабре.
Вот по ссылке их сайт есть, qz.com, там можно найти всю информацию и спросить.
Как именно там программисты всё-таки общаются? Через iAutonomous? Я надеюсь, там есть функция «просто сказать тому-то то-то»?
Я полагаю, там просто есть комментарии к задачам.
Интересно кто увольнял неправильных программистов или кто решал что нужно нанять новых.
Действительно, этот момент за кадром. Я так понимаю, что этот автор статьи как раз один из основателей бизнеса, и он по совместительству HR.
С задачами понятно. А как решаются более глобальные задачи, например, как они обсуждают/утверждают архитектуру фронтенда или бакенда не важно?
Я считаю, что наша главная особенность – качество нанимаемых нами инженеров.


Так с менеджерами то же самое.
Sign up to leave a comment.

Articles