Комментарии 22
Почти каждый проект в Basecamp делает команда из трёх человек или меньше (два программиста, один дизайнер), а существенное количество групп состоит из одного человека (программист или дизайнер).
Могу ошибаться, но так делается во всех небольших компаниях, нанимают одного программиста за 2 копейки из колхоза, и вешают на него все: администрирование серверов, обслуживание орг техники в офисе, фронтенд, бекенд, администрирование и проектирование БД, написание тестов для всего и т.д.
С точки зрения бизнеса, это выгодно — оптимизируются расходы и избегается проблема роста. Но это порождает множество других проблем связанных с качеством продукта, скоростью исправления багов, обслуживания, разработкой нового функционала и т.д, а руководитель, как правило считает, что это не его ошибка, а плохая работа подчиненных.
Мне кажется, автор имел ввиду не один человек, который делает всё, а минимальная команда, которая делает конкретный проект. При чём тут оптимизация расходов и эникейшик? Если проект на столько простой, что его может сделать за полтора месяца пара рубистов (они вроде руби любят), зачем нужно больше?
Потому что на проекте все равно нужен кто-то, кто будет выполнять роль PM, BA, QA, UI/UX дизайнера, Архитектора, Админа и прочее.
И если у вас команда из 2-3 человек, это валится на кого-то одного из них)
Вы по ссылкам ходили? У них там хорошо описан процесс, с примерами… Не нужно в ИХ проекте то множество аббревиатур, которые вы написали…
Не бывает "не нужно".
Тут или эти роли выполняются кем-то на много проектов сразу, или же они выполняются кем-то из людей в проекте.
Возможно, я не прав, но я пока придерживаюсь такой позиции.
Если у них все нормально работает, значит у них первый вариант и они немного лукавят, насчет размера команд.
Не факт. Полно таких небольших, но важных проектов, где лучше всего иметь команду из 2-3-4 senior'ов. Это могут быть feasibility, proof-of-concept проеты, исследования, платные доработки для конкретного клиента…
Это сложно назвать проектом, это обычно отдельные задачи.
Я не прав?
Бывают разные. Если задумка инженерно сложная, то feasibility может стать в 36 человеко-месяцев или около того. 1-2 исследователя, столько же программистов. Если взлетает — тогда большая команда берётся за продуктизацию.
Не знаю насколько это распространённая практика, но мне доводилось участвовать в подобных проектах не раз.
Не знаю насколько это распространённая практика, но мне доводилось участвовать в подобных проектах не раз.
Ого, сколько тут обиженных эникейщиков и ленящихся почитать ссылки из статьи… Удачи вам )))))
Меня вот этот абзац смутил:
>> Если бы они только приложили больше усилий, чтобы избежать будущих проблем, а не решить текущие, которые создали себе перед этим, то могли бы достичь существенно большего прогресса за меньшее время.
Какое-то слишком сильное обощение.
Надо иметь очень большой опыт (предвиденье?) чтобы знать каких именно будущих проблем нужно избегать. Как там классики говорили «преждевременная оптимизация — зло», «не дайте себя запутать, астронавтам архитектуры» и тому подобное.
Насколько я понял они решают это тем что берут только отобраные проекты, с развитием которых они более менее знакомы. М-м-м… но это как-то слишком просто, нет?
>> Если бы они только приложили больше усилий, чтобы избежать будущих проблем, а не решить текущие, которые создали себе перед этим, то могли бы достичь существенно большего прогресса за меньшее время.
Какое-то слишком сильное обощение.
Надо иметь очень большой опыт (предвиденье?) чтобы знать каких именно будущих проблем нужно избегать. Как там классики говорили «преждевременная оптимизация — зло», «не дайте себя запутать, астронавтам архитектуры» и тому подобное.
Насколько я понял они решают это тем что берут только отобраные проекты, с развитием которых они более менее знакомы. М-м-м… но это как-то слишком просто, нет?
Да они вообще за простые решения. У них есть пара отличных книг: Getting things done и Rework — там они за простоту и борются.
Надо иметь очень большой опыт (предвиденье?) чтобы знать каких именно будущих проблем нужно избегать. Как там классики говорили «преждевременная оптимизация — зло»,
В моей компании утверждение «преждевременная оптимизация — зло» — как раз таки зло. И продукты годами работают без багов. А вот подход «починим/оптимизируем потом» никогда не работает. Потому-что «потом» никогда не наступает.
Я подозреваю что у меня слишком мало опыта для преждевременной оптимизации что скорости, что структуры даных, что связей.
Почему-то после большинства попыток оптимизаций появляется новое требование заказчика, котороехерит уничтожает эту попытку, и приходится впопыхах все переделывать.
Утешает то, что я замечал это и за разработчиками фреймворков, и либ, и всеми-всеми, где проекты хоть чуть-чуть сложные )
Конечно какие-то оптимизации нужны. Понятно что лучше использовать (я упрощаю) базу данных для хранения инфы о пользователях вместо файла, но вот дальше…
Почему-то после большинства попыток оптимизаций появляется новое требование заказчика, которое
Утешает то, что я замечал это и за разработчиками фреймворков, и либ, и всеми-всеми, где проекты хоть чуть-чуть сложные )
Конечно какие-то оптимизации нужны. Понятно что лучше использовать (я упрощаю) базу данных для хранения инфы о пользователях вместо файла, но вот дальше…
Мне кажется, вы не совсем правильно его понимаете. Это выражение не говорит о том, что вообще не нужно оптимизировать. Но то, что нужно выбирать решение оптимальное по соотношению затраты<->производительность<->поддерживаемость, а не только по производительность.
Сдается мне проблема тут не в том, что злом является преждевременная оптимизация, а в том, что «потом» никогда не наступает.
Сложно найти что-то более деморализующее, чем долгосрочный проект, которому не видно конца.
Как-то спорно. Меня, например, наоборот деморализовало, когда меня бросали между проектами каждый месяц, зато работать на одном и том же большом проекте три года — всегда пожалуйста (если он достаточно большой, чтоб можно было раз в полгода-год менять специализацию работы).
И что, у вас там совсем не было сроков, vision и прочих штук?
Там важное уточнение, что "не видно конца". Думаю, тут имеется виду, когда у вас проект настолько большой, что вы даже не знаете, когда он будет готов, а только пилите, пилите и пилите.
Сначала удивило:
«У нас есть некоторые идеи общего характера, куда мы хотим развиваться, но эти идеи мы держим в голове и редко записываем.»
А потом понял: они один раз приняли решение на будущее, чем в принципе хотят заниматься.
И теперь, регулярно, но понемножку, приспосабливаясь к изменениям в мире, не чувствуют на себе довлеющих обязательств пятилеток ).
Молодцы. Поверил, что в их нише это работает.
По поводу узких мест и мыть посуду после еды — большое спасибо!
Я на работе поначалу пытался с утра делать как можно больше срочных дел, чтобы разгребаться после обеда.
Так как надо сначала дать ответ контрагенту, а уже потом можно внести данные в базу, сначала надо сделать и отдать в работу аналитику и заказ, а уже потом зарегистрировать их…
Но, как оказалось, что даже промежуток в полдня заставляет потом тратить на эту зачистку хвостов намного больше времени, чем когда задача делается целиком.
После переосмысления теперь немного упираюсь, когда пытаются навесить несколько новых срочных задач, пока не доделал предыдущие. В большинстве случаев руководство понимает и соглашается. В 20-30% случаев срочность новых «вводных» перевешивает, и приходится-таки откладывать доделывание на потом. Но и отвоёванные 70-80% позволяют гораздо меньше уставать в течение дня. Как бы меньше незакрытых вопросов одновременно висит в голове, от этого легче.
Спасибо за статью!
«У нас есть некоторые идеи общего характера, куда мы хотим развиваться, но эти идеи мы держим в голове и редко записываем.»
А потом понял: они один раз приняли решение на будущее, чем в принципе хотят заниматься.
И теперь, регулярно, но понемножку, приспосабливаясь к изменениям в мире, не чувствуют на себе довлеющих обязательств пятилеток ).
Молодцы. Поверил, что в их нише это работает.
По поводу узких мест и мыть посуду после еды — большое спасибо!
Я на работе поначалу пытался с утра делать как можно больше срочных дел, чтобы разгребаться после обеда.
Так как надо сначала дать ответ контрагенту, а уже потом можно внести данные в базу, сначала надо сделать и отдать в работу аналитику и заказ, а уже потом зарегистрировать их…
Но, как оказалось, что даже промежуток в полдня заставляет потом тратить на эту зачистку хвостов намного больше времени, чем когда задача делается целиком.
После переосмысления теперь немного упираюсь, когда пытаются навесить несколько новых срочных задач, пока не доделал предыдущие. В большинстве случаев руководство понимает и соглашается. В 20-30% случаев срочность новых «вводных» перевешивает, и приходится-таки откладывать доделывание на потом. Но и отвоёванные 70-80% позволяют гораздо меньше уставать в течение дня. Как бы меньше незакрытых вопросов одновременно висит в голове, от этого легче.
Спасибо за статью!
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Покажите мне бизнес-проблему, и я постараюсь её избежать