Comments 49
А зачем было соглашаться на позицию менеджера, если нравилось инженерить?
О, это интересный вопрос и я немного подвисла, компания была совсем маленькая, и в общем была ситуация «если не я то кто», и уходить из компании тоже не хотелось — было очень интересно и работа горела, и прямо видение было. В общем из минусов только руководство, потом я поняла, что оно тоже плюс, главное уметь его правильно готовить.
Это очень классно управлять развитием проекта, двигать его в том направлении которое считаешь правильным, когда его успех и техническое исполнение фактически зависит от тебя, от твоих знаний и принимаемых решений.
Согласен с каждым пунктом и разъяснением.
Слегка расширил бы пункт про «Делать — 5 минут делать, а объяснять — 30 минут».
Объяснение тоже можно делегировать — попросить сначала самостоятельно зафиксировать план работы (в виде документа, который позже можно расшарить), и по этому плану пройтись, подсказать, где ошибки, это всё человек фиксирует и расшаривает.
Двойной профит — документация написана, человек потренировался составлять план, оформлять в человекопонятном виде, ваше время на написание сэкономлено.
Слегка расширил бы пункт про «Делать — 5 минут делать, а объяснять — 30 минут».
Объяснение тоже можно делегировать — попросить сначала самостоятельно зафиксировать план работы (в виде документа, который позже можно расшарить), и по этому плану пройтись, подсказать, где ошибки, это всё человек фиксирует и расшаривает.
Двойной профит — документация написана, человек потренировался составлять план, оформлять в человекопонятном виде, ваше время на написание сэкономлено.
Как же всё это знакомо. :)
«Хорошее решение в понедельник лучше, чем отличное в пятницу»
Это не всегда работает так же хорошо, как и звучит. Есть задачи, например, на которые завязывается потом очень много всего. И сделав это «хорошо в понедельник» потом можно выбросить в мусор очень много человекочасов впоследствии, чтобы переписывать с нуля то, что уже невозможно поддерживать, т.к. «больше не гнётся». А всё потому, что задачу делегировали «просто хорошему разработчику», когда ее надо было сделать лучшему, а заказчику подождать чуть больше расчётного.
Ну и самая мякотка, когда на такие «хорошие» и недописанные, но быстро пущенные в прод решения завязываются системы, от которых начинают зависеть жизни и здоровье людей. Сами эти системы могут быть сколь угодно великолепны и протестированы, но беда придет откуда не ждали.
Наша команда уже чаще баги в сторонних библиотеках и системах находит на продакшене, чем в своем вдоль и поперек протестированном коде. И ощущение, что чем дальше — тем больше этих багов будет в любой программной экосистеме из-за таких вот «хороших решений в понедельник».
Это не всегда работает так же хорошо, как и звучит. Есть задачи, например, на которые завязывается потом очень много всего. И сделав это «хорошо в понедельник» потом можно выбросить в мусор очень много человекочасов впоследствии, чтобы переписывать с нуля то, что уже невозможно поддерживать, т.к. «больше не гнётся». А всё потому, что задачу делегировали «просто хорошему разработчику», когда ее надо было сделать лучшему, а заказчику подождать чуть больше расчётного.
Ну и самая мякотка, когда на такие «хорошие» и недописанные, но быстро пущенные в прод решения завязываются системы, от которых начинают зависеть жизни и здоровье людей. Сами эти системы могут быть сколь угодно великолепны и протестированы, но беда придет откуда не ждали.
Наша команда уже чаще баги в сторонних библиотеках и системах находит на продакшене, чем в своем вдоль и поперек протестированном коде. И ощущение, что чем дальше — тем больше этих багов будет в любой программной экосистеме из-за таких вот «хороших решений в понедельник».
Это очень важный момент — в идеале, если задача критичная, а та которую вы описали именно такая, она должна быть одобрена отличным разработчиком. То есть хороший может ею заниматься, но под контролем отличного как спеца.
Также если это вдруг какое то изменение в архитектуре, либо в каком то критичном узле — это не означает, что делать это может только отличный, и не может хороший, может. Но решение должно быть просмотрено, обсуждено и утверждено. И так же разделение на этапы — и подтверждение что на каждом этапе происходит то, что ожидалось — важно. Опять же code review — тоже в этом случае важный момент.
Кроме того надо глянуть, чем занят отличный разработчик и посмотреть нельзя ли что-нибудь у него забрать и передать кому нибудь еще, возможно так и время для такой важной задачи появится.
Есть вещи, где качеством нельзя жертвовать в угоду скорости, но их обычно немного. Если речь не идет о здоровье\безопасности людей, ну и о деньгах наверное.
Также если это вдруг какое то изменение в архитектуре, либо в каком то критичном узле — это не означает, что делать это может только отличный, и не может хороший, может. Но решение должно быть просмотрено, обсуждено и утверждено. И так же разделение на этапы — и подтверждение что на каждом этапе происходит то, что ожидалось — важно. Опять же code review — тоже в этом случае важный момент.
Кроме того надо глянуть, чем занят отличный разработчик и посмотреть нельзя ли что-нибудь у него забрать и передать кому нибудь еще, возможно так и время для такой важной задачи появится.
Есть вещи, где качеством нельзя жертвовать в угоду скорости, но их обычно немного. Если речь не идет о здоровье\безопасности людей, ну и о деньгах наверное.
Верно, ну и не стоит забывать о том, что не делегируются задачи касаемо оплаты труда (премирования) своей службы и бюджетирования. Не очень приятно находясь в другой стране в отпуске получить звонок от ГД с вопросом… «А какого фига премия такая большая? (в 10 раз больше чем обычно) „
Где откровение?
Читаю третью статью и все просто ни о чем.
Кто подскажет, как добавить конкретного автора а анти-избранные, чтобы в ленте и не появлялся?
К сожалению это проблема повсеместна. Не только в мелких конторах но и даже в банках и на больших предприятиях есть люди, которые занимают позиции без нужного проф. образования.
Когда нет нормального управления то всё превращается в неуправляемый самодел. Как например, это делегирование. Подарите управленцу книжку о менеджменте в картинках, может хоть какая нибудь организация появится…
Когда нет нормального управления то всё превращается в неуправляемый самодел. Как например, это делегирование. Подарите управленцу книжку о менеджменте в картинках, может хоть какая нибудь организация появится…
Брукс в "мифическом человеко-месяце" прекрасно описал, к чему приводит такое делегирование. Вкратце — проектировать (и вообще приниать существенные решения) должны наиболее грамотные игроки команды. Попытка отдать сложную задачу подчиненным меньшей квалификации — лишь затягивает сроки.
Более подробное описание ценой в миллион долларов.
Очень неприятно совершить ошибку стоимостью в миллион долларов, но зато она надолго запоминается. Я отчетливо помню тот день, когда мы приняли решение о том, как практически организовать составление внешних спецификаций для OS/360. Менеджер по архитектуре, менеджер по реализации управляющей программы и я прорабатывали план, график и разделение обязанностей.
У менеджера по архитектуре было 10 хороших специалистов. Он утверждал, что они в состоянии написать спецификации и сделать это надлежащим образом. Это должно было занять 10 месяцев — на три больше, чем отводилось по графику.
У менеджера по реализации управляющей программы было 150 человек. Он заявлял, что они могут подготовить спецификации, при этом группа архитекторов выполняла бы координирующие функции. Обещалось, что это будет сделано хорошо и практично, с соблюдением сроков. Более того, если оставить спецификации группе архитекторов, его 150 человек в течение десятимесяцев будут бить баклуши.
На это менеджер по архитектуре возразил, что если я сделаю ответственной за написание спецификаций группу управляющей программы, то результата в срок не будет: он все равно задержится на три месяца, но по качеству будет много хуже.
Так оно и оказалось в действительности. Он оказался прав в обоих пунктах. Кроме того, из-за отсутствия концептуальной целостности создание и внесение изменений в систему оказались значительно более дорого
Вы правы, нельзя нанять джуниора и делегировать ему задачу по проектированию ядра системы например. Везде должна быть мера и здравый смысл. Идея в том, что сложность отдаваемых задач должна наращиваться постепенно.
Это как с мышцами, если есть тренер, который поднимает 100 кг и приду я, то я их не подниму как не делегируй. Но если я приду, мне тренер даст 3 кг, я с ними освоюсь и он не будет увеличивать нагрузку, то и результата будет немного, и я возможно расстроюсь и уйду к другому тренеру. Мне кажется так и с задачами и с ростом подчиненных. Должен быть определенный баланс между «как попасть в сроки», «сделать хорошо», и «прокачать людей». И последнее тоже не нужно забывать, ведь опять же никто из нас не пришел после универа супер профи, каждый человек растет благодаря обучению и решению более сложных задач.
Это как с мышцами, если есть тренер, который поднимает 100 кг и приду я, то я их не подниму как не делегируй. Но если я приду, мне тренер даст 3 кг, я с ними освоюсь и он не будет увеличивать нагрузку, то и результата будет немного, и я возможно расстроюсь и уйду к другому тренеру. Мне кажется так и с задачами и с ростом подчиненных. Должен быть определенный баланс между «как попасть в сроки», «сделать хорошо», и «прокачать людей». И последнее тоже не нужно забывать, ведь опять же никто из нас не пришел после универа супер профи, каждый человек растет благодаря обучению и решению более сложных задач.
Зависит от того, что вы хотите. Если у вас цель вырастить крутую команду — то вы правы. А если цель — сделать качественный проект — то нет.
Тот же тренер, если готовит команду на Олимпиаду — просто выкинет тех, кто не поднимает 150 кг.
P.S. Команда разработчиков ядра OS/360 — это далеко не юниоры были. Юниоры ядро операционной системы вообще-то не пишут.
Тот же тренер, если готовит команду на Олимпиаду — просто выкинет тех, кто не поднимает 150 кг.
P.S. Команда разработчиков ядра OS/360 — это далеко не юниоры были. Юниоры ядро операционной системы вообще-то не пишут.
Зависит от того, что вы хотите. Если у вас цель вырастить крутую команду — то вы правы. А если цель — сделать качественный проект — то нет.
Но сроки то никто не отменял.
Как мне говорил мой начальник когда я стал руководителем группы: не хочешь/не умеешь поручать работу своим подчиненным — делай сам, оставайся после работы, выходи в выходные.
И что бы сделать качественный проект приходится меньше писать код самому, а больше распределять и объяснять таски, продумывать алгоритмы и ревьювить код своей команды.
В этом отличие ненастоящего программирования от настоящего. В ненастоящем сроки, «научно» подсчитанные программистом, подлежат умножению вначале на пи, потом на е. И вообще, сроки — далеко не самое важное.
Вы платье где будете шить? У портнихи, которая соблюдает сроки? Или у той, которая сошьет красиво и по вашей фигуре? Сроки горят — значит в магазине покупаете готовое, потом подгоняете по фигуре, хуяк-хуяк и в продакшн.
Вы почитайте Брукса. А потом проверьте его выводы с карандашом и бумажкой. Добавление людей в проект лишь замедляет работу при том же качестве. Или ускоряет её — за счет снижения качества.
Я понимаю, что в вашем мире важнее всего сроки. А в нашем — нет.
Вы платье где будете шить? У портнихи, которая соблюдает сроки? Или у той, которая сошьет красиво и по вашей фигуре? Сроки горят — значит в магазине покупаете готовое, потом подгоняете по фигуре, хуяк-хуяк и в продакшн.
Вы почитайте Брукса. А потом проверьте его выводы с карандашом и бумажкой. Добавление людей в проект лишь замедляет работу при том же качестве. Или ускоряет её — за счет снижения качества.
Я понимаю, что в вашем мире важнее всего сроки. А в нашем — нет.
Что то у вас все в одну кучу смешано…
Инопланетяне среди нас? ))
Если шьется свадебное платье то как бы красиво оно не выглядело если просран дедлайн (дата свадьбы) заказчику оно больше не нужно.
Сроки могут гореть из-за того что портниха большую часть времени потратила на вышивку всяких рюшечек а за основную работу браться не спешила.
Если перевести это на нашу область: реализовывались и постоянно переписывались мелкие фичи а за основной функционал никто и не взялся.
Тогда по вашему получается — идеален проект с одним разработчиком. Так вы ничего серьезного не сделаете.
А если серьезно то Брукса я читал а вот вы сделали неправильный вывод.
Правильно так: добавление людей в проект на поздних стадиях разработки лишь отодвигает срок сдачи проекта.
Я понимаю, что в вашем мире важнее всего сроки. А в нашем — нет.
Инопланетяне среди нас? ))
Вы платье где будете шить? У портнихи, которая соблюдает сроки? Или у той, которая сошьет красиво и по вашей фигуре? Сроки горят — значит в магазине покупаете готовое, потом подгоняете по фигуре, хуяк-хуяк и в продакшн.
Если шьется свадебное платье то как бы красиво оно не выглядело если просран дедлайн (дата свадьбы) заказчику оно больше не нужно.
Сроки могут гореть из-за того что портниха большую часть времени потратила на вышивку всяких рюшечек а за основную работу браться не спешила.
Если перевести это на нашу область: реализовывались и постоянно переписывались мелкие фичи а за основной функционал никто и не взялся.
Вы почитайте Брукса. А потом проверьте его выводы с карандашом и бумажкой. Добавление людей в проект лишь замедляет работу при том же качестве. Или ускоряет её — за счет снижения качества.
Тогда по вашему получается — идеален проект с одним разработчиком. Так вы ничего серьезного не сделаете.
А если серьезно то Брукса я читал а вот вы сделали неправильный вывод.
Правильно так: добавление людей в проект на поздних стадиях разработки лишь отодвигает срок сдачи проекта.
Я уже цитировал историю, как 10 архитекторов заменили на 150 программистов и как это затянуло сроки. Вряд ли разработку спецификаций можно назвать «поздней стадией». :-)
А идеально — вместо 5 разработчиков нанять одного и платить ему в 4 раза больше.
В целом правильное число людей на проекте — 3-5, границы от 1 до 7.
И да, мне везет заниматься интересными проектами в компании очень крутых людей.
Мы сделали систему в 135 тысяч строк. Впятером. При этом единственным «juniorом» был будущий технический директор Jet Brains — он делал экранную библиотеку. 90% кода мы написали вдвоем с Антоном. Покойного Антона Креницкого вы, может быть, знаете по Auslogic registry defrag. Ещё один человек писал SCADA + некоторые отдельные части. Плюс шеф, который осуществлял общее руководство.
Опишу проект на хабре — кину ссылку. Пока что так.
Сейчас со мной работает человек, который в одиночку написал ГАИшный фоторадар (несколько тысяч установок по стране). И он один сделал нашу компанию из чисто софверной в софтерно-хардовую.
А идеально — вместо 5 разработчиков нанять одного и платить ему в 4 раза больше.
В целом правильное число людей на проекте — 3-5, границы от 1 до 7.
И да, мне везет заниматься интересными проектами в компании очень крутых людей.
Так вы ничего серьезного не сделаете
Мы сделали систему в 135 тысяч строк. Впятером. При этом единственным «juniorом» был будущий технический директор Jet Brains — он делал экранную библиотеку. 90% кода мы написали вдвоем с Антоном. Покойного Антона Креницкого вы, может быть, знаете по Auslogic registry defrag. Ещё один человек писал SCADA + некоторые отдельные части. Плюс шеф, который осуществлял общее руководство.
Опишу проект на хабре — кину ссылку. Пока что так.
Сейчас со мной работает человек, который в одиночку написал ГАИшный фоторадар (несколько тысяч установок по стране). И он один сделал нашу компанию из чисто софверной в софтерно-хардовую.
Я уже цитировал историю, как 10 архитекторов заменили на 150 программистов и как это затянуло сроки. Вряд ли разработку спецификаций можно назвать «поздней стадией». :-)
Если вы цитируете кого-то надо указывать полную цитату, без своих правок, в оригинальной цитате Брукс писал именно про поздние стадии.
Понятно что задачу можно распараллеливать на подзадачи только до какого то предела.
А идеально — вместо 5 разработчиков нанять одного и платить ему в 4 раза больше.
А при постройке дома вместо бригады строителей нанять одного и платить ему как за целую бригаду…
Похоже у вас другая крайность, вы не хотите делегировать хоть что-то кому-нибудь другому.
Видел уже таких руководителей чуть не довёвших предприятие до банкротства:
При модернизации предприятия главный инженер решил все задачи решать лично, что было этому причиной не знаю, может не умел руководить, может боялся что его подсидят, но в результате, из-за огромного количества вопросов и проблем, он успевал решать только самые мелкие задачи, от крупных и более серьезных его постоянно отвлекали. Если бы его не сменили на более адекватного руководителя закончилось все бы очень плохо.
Я вам очень рекомендую перечитать Брукса и сравнить цитату с полным текстом. Судя по вашим словами, Брукса вы так и не прочли. Более того, даже не потрудились прочесть цитату.
Мы не строим дома (это делает компилятор и линкер), мы проектируем их. Делегировать «хоть что-нибудь» это значит замедлить проект. Делегировать нужно очень крупные части. Или по вертикали — отдельные дома или по горизонтали — вся электрика или вся сантехника.
Вы путаете менеджмент с программированием. Но я ничего не говорил про менеджерские задачи — я в них не сильно разбираюсь.
Чуть о делении в наше системе и об увеличении объема работы вследствие деления:
Шеф участвовал во всех частях. Не написал ни одной строчки кода, но все технические решения обговаривались с ним. Придумал кучу интересных идей на самых разных уровнях системы. Кроме того, на нём было документирование и менеджмент.
Вот вам пожалуйста — бригада главного хирурга в действии. Никакого делегирования фичей, отдается или горизонтально (вся документация, весь менеджмент, вся экранная библиотека) или вертикально (вся SCADA, вся СУБД).
А отдача фичей экономит всего лишь 20-30 процентов (если реализацию без делегирования принять за 100%). Можете по своему опыту проверить.
Статья про проект пишется, выйдет под названием «Два часа на отладку в месяц».
А если уж вам так нравится аналогия со строительством, то бригада таджиков сделает квартирный ремонт не быстрее пары русских. И выйдет это дороже. Просто пару русских вы будете долго искать, а бригаду таджиков найдете за день.
И ещё раз цитата из Брукса про ошибку ценой в миллион долларов
Очень неприятно совершить ошибку стоимостью в миллион долларов, но зато она надолго запоминается. Я отчетливо помню тот день, когда мы приняли решение о том, как практически организовать составление внешних спецификаций для OS/360. Менеджер по архитектуре, менеджер по реализации управляющей программы и я прорабатывали план, график и разделение обязанностей.
У менеджера по архитектуре было 10 хороших специалистов. Он утверждал, что они в состоянии написать спецификации и сделать это надлежащим образом. Это должно было занять 10 месяцев — на три больше, чем отводилось по графику.
У менеджера по реализации управляющей программы было 150 человек. Он заявлял, что они могут подготовить спецификации, при этом группа архитекторов выполняла бы координирующие функции. Обещалось, что это будет сделано хорошо и практично, с соблюдением сроков. Более того, если оставить спецификации группе архитекторов, его 150 человек в течение десятимесяцев будут бить баклуши.
На это менеджер по архитектуре возразил, что если я сделаю ответственной за написание спецификаций группу управляющей программы, то результата в срок не будет: он все равно задержится на три месяца, но по качеству будет много хуже.
Так оно и оказалось в действительности. Он оказался прав в обоих пунктах. Кроме того, из-за отсутствия концептуальной целостности создание и внесение изменений в систему оказались значительно более дорого
Мы не строим дома (это делает компилятор и линкер), мы проектируем их. Делегировать «хоть что-нибудь» это значит замедлить проект. Делегировать нужно очень крупные части. Или по вертикали — отдельные дома или по горизонтали — вся электрика или вся сантехника.
Вы путаете менеджмент с программированием. Но я ничего не говорил про менеджерские задачи — я в них не сильно разбираюсь.
Чуть о делении в наше системе и об увеличении объема работы вследствие деления:
- Экранная библиотека — Дима Жемеров. 10% — за счет исправления тонких ошибок, которые вылезли лишь на поздних стадиях.
- СУБД — Антон Креницкий. Где-то 30% из-за того, что вместе писали библиотеку, используемую обоими.
- ВИЗГУН (popup приложение) — Игорь. Примерно 15%, тонкости отлаживали вместе
- OPC-Сервер — Игорь. 5% на пояснение, как и что из нашей части вызывать.
- SCADA — Игорь. 0%, даже тексты никогда не видел.
- СЕРВЕР — я сам. 0%.
- SHOVEL (часть, исполняемая в контроллерах) — я сам. 0%
- РМА (GUI-клиент)- я сам. 0%
Шеф участвовал во всех частях. Не написал ни одной строчки кода, но все технические решения обговаривались с ним. Придумал кучу интересных идей на самых разных уровнях системы. Кроме того, на нём было документирование и менеджмент.
Вот вам пожалуйста — бригада главного хирурга в действии. Никакого делегирования фичей, отдается или горизонтально (вся документация, весь менеджмент, вся экранная библиотека) или вертикально (вся SCADA, вся СУБД).
А отдача фичей экономит всего лишь 20-30 процентов (если реализацию без делегирования принять за 100%). Можете по своему опыту проверить.
Статья про проект пишется, выйдет под названием «Два часа на отладку в месяц».
А если уж вам так нравится аналогия со строительством, то бригада таджиков сделает квартирный ремонт не быстрее пары русских. И выйдет это дороже. Просто пару русских вы будете долго искать, а бригаду таджиков найдете за день.
А если уж вам так нравится аналогия со строительством, то бригада таджиков сделает квартирный ремонт не быстрее пары русских. И выйдет это дороже. Просто пару русских вы будете долго искать, а бригаду таджиков найдете за день.
Я для вас аналогии подбирал, вы же их начали приводить, строительство показалась вполне удобной аналогией.
Вы почему то выбираете работы объем и сложность которых позволяет их выполнить одному человеку и распространяете этот вывод на всё.
Я надеюсь вы же не думаете что пары русских будет достаточно для постройки современного многоквартирного дома? Причем которые построят дом не медленнее нормальной бригады строителей? Да, причем постройка дома парой человек (по вашему в идеале одному) в результате выйдет дешевле?
Это все получается из ваших слов.
Шеф участвовал во всех частях. Не написал ни одной строчки кода, но все технические решения обговаривались с ним. Придумал кучу интересных идей на самых разных уровнях системы. Кроме того, на нём было документирование и менеджмент.
Вы же сами приводите пример делегирования, причем, раз вы приводите проект в пример, успешного делегирования.
Делегировать «хоть что-нибудь» это значит замедлить проект.
Ваш шеф тратил свое время участвуя в совещаниях, обсуждая технические технические решения, объясняя вам свои идеи и проверяя то ли вы сделали что он хотел. По вашему это зло и так делать неправильно и это только затягивает сроки.
Думаю это был не единственный проект на фирме и он участвовал во всех, а если бы он не делегировал разработку проекта вам про остальные можно было бы забыть, времени на них бы не было.
Делегировать нужно очень крупные части. Или по вертикали — отдельные дома или по горизонтали — вся электрика или вся сантехника.
Похоже вы просто не смогли разбить свою часть проекта на подчасти.
Ваш шеф тратил свое время участвуя в совещаниях, обсуждая технические технические решения, объясняя вам свои идеи и проверяя то ли вы сделали что он хотел. По вашему это зло и так делать неправильно и это только затягивает сроки.
Угу, это зло, потому было ровно наоборот. Это я подходил к шефу, рассказывал свои варианты решения и их последствия и спрашивал, а не возьмет ли он ответственность за выбор. Потому что я сам — обычно торможу, пока не продумаю последствия до конца.
Похоже вы просто не смогли разбить свою часть проекта на подчасти.
В сервере из двух десятков одновременно работающих тредов — достаточно подчастей. В том числе там был и компилятор и декомпилятор. Но… отдача части проекта другому разработчику увеличила бы и общую трудоемкость и время выполнения проекта.
Я надеюсь вы же не думаете что пары русских будет достаточно для постройки современного многоквартирного дома? Причем которые построят дом не медленнее нормальной бригады строителей? Да, причем постройка дома парой человек (по вашему в идеале одному) в результате выйдет дешевле?
За стоимость хрущевки в Питере — можно купить коттедж 250 кв. метров в Калифорнии. Строится коттедж в 325 кв.метров почти в одиночку (женщина + четверо детей, причем младшему два года) за 9 месяцев.
Так что если вам нужны квадратные метры — дешевле и быстрее построить коттеджный поселок, чем многоквартирный дом. И строить его с вертикальным разделением — бригада по 2-3 человека на дом. И с горизонтальным: 2-3 сантехника, 2-3 электрика, 2-3 кровельщика, 2-3 водителя, 1-2 логиста, 1-2 менеджера…
Многоэтажки хороши только тем, что эффективно используют землю. Во всем остальном — они дороже, строятся медленней и просто хуже по качеству. Да и строят их с 18ого века, так что о современности речь вести трудно. И высотное строительство — это тоже 18 век. Петр 1 планировал построить в Кронштадте маяк высотой в 213 метров. Причем строительство прекратилось из-за его смерти, а не по техническим причинам.
Любуйтесь. Высотное строительство 18 века
Что у вас за проект такой, что делается только огромной командной? Может архитектура неправильная? Может ваш проект можно побить на части, и на каждый поставить «бригаду главного хирурга» из 2-3 человек?
За стоимость хрущевки в Питере — можно купить коттедж 250 кв. метров в Калифорнии. Строится коттедж в 325 кв.метров почти в одиночку (женщина + четверо детей, причем младшему два года) за 9 месяцев.
Так что если вам нужны квадратные метры — дешевле и быстрее построить коттеджный поселок, чем многоквартирный дом. И строить его с вертикальным разделением — бригада по 2-3 человека на дом. И с горизонтальным: 2-3 сантехника, 2-3 электрика, 2-3 кровельщика, 2-3 водителя, 1-2 логиста, 1-2 менеджера…
Многоэтажки хороши только тем, что эффективно используют землю. Во всем остальном — они дороже, строятся медленней и просто хуже по качеству. Да и строят их с 18ого века, так что о современности речь вести трудно. И высотное строительство — это тоже 18 век. Петр 1 планировал построить в Кронштадте маяк высотой в 213 метров. Причем строительство прекратилось из-за его смерти, а не по техническим причинам.
Вы какой то демагогией и словоблудием занимаетесь.
Я привел пример со строительством как простую и понятную аналогию.
А вы зачем все это написали? Причем здесь что за стоимость хрущевки в Питере можно купить коттедж в Калифорнии??? Какая разница для аналогии какие плюсы и минусы в многоэтажках??
Если заказчику нужен именно многоквартирный дом вы сделаете ему коттеджный поселок и потом будете грузить его всем этим???
Вы о своем кошельке думаете или о заказчике? Если о своем — то вы так и будете строить многоквартирных монстров. А если вы думаете о заказчике — то ему нужно побольше метров, побыстрее и подешевле. И unix way, то есть коттеджи, позволяет отлично масштабироваться.
Что у вас за задача такая, что заказчик сам хочет многоквартирного монстра?
Что у вас за задача такая, что заказчик сам хочет многоквартирного монстра?
Да и строят их с 18ого века, так что о современности речь вести трудно
Я вас огорчу. Вы ничерта не знаете в истории строительства.
Поэтому дальнейшие рассуждения можно выкинуть на помойку.
В начале нашей эры в Риме строили 5+ этажей жилые здания.
Ну и чтобы сравнить ваш коттедж на 325 м2 за 9 месяцев
Уолл Стрит 40, 70 этажей 282 м.
построили за 11 месяцев.
Сравнивать площади будете?
Давайте сравним площадь на одного строителя?
Сравнивайте.
103,278.0 m2
$190,964,563.58 (в ценах 2017 года)
Количество строителей быстро не нагуглилось.
Попутно сравните сроки жизни этих зданий и прогнозные сроки сколько они еще проживут.
103,278.0 m2
$190,964,563.58 (в ценах 2017 года)
Количество строителей быстро не нагуглилось.
Попутно сравните сроки жизни этих зданий и прогнозные сроки сколько они еще проживут.
1849 долларов за метр. И это только за стройку. Ну и сравните с ценами коттеджного строительства.
Продажные цены у пятиэтажек — примерно такого же порядка (цена стройки ниже раза в два). Но живут они намного меньше коттеджей, Проектировались так вообще на 25 лет, прожили — лет 50. Коттеджи — лет на 100 рассчитываются.
Так что время жизни можно при любой технологии обеспечить.
Жду количество строителей — это самое интересное.
Продажные цены у пятиэтажек — примерно такого же порядка (цена стройки ниже раза в два). Но живут они намного меньше коттеджей, Проектировались так вообще на 25 лет, прожили — лет 50. Коттеджи — лет на 100 рассчитываются.
Так что время жизни можно при любой технологии обеспечить.
Жду количество строителей — это самое интересное.
Коттеджи — лет на 100 рассчитываются
Вы фото той стройки видели? Там брус неизвестного качества и обработки.
50 лет в лучшем случае. Если жучок не съест.
И учитывайте тот факт, что у меня нет информации входит ли в цену стоимость земли. В стройках в центре города она может занимать существенную долю.
И, да, строителей вы погуглите самостоятельно.
Из легкодоступного это 12000 человек для Бурж Халифа, но там площади в 3.5 раза больше и высота во столько же раз тоже, но и строилось оно с более современной техникой.
Плюс есть такая «мелочь» как внутренние отделочные работы, которые могут занимать основную массу работающих.
Так что время жизни можно при любой технологии обеспечить.
Не интересует.
Вы привели конкретный пример. Вот его и обсуждайте, а не сферического коня в вакууме.
Образно говоря «при любой технологии» имеет сильно разный TCO (total cost of ownership)
Цена земли — это единственный фактор, делающий выгодным многоэтажное строительство. ТСО у многоэтажек выше, ибо ещё и дороже обслуживание. Подача воды, лифты… Те же стены — просто со стремянки не покрасить. Ну и так далее…
Подумайте, почему США, где очень сильно считают экономику, одноэтажное? Ну ладно, 2-3 этажное?
Подумайте, почему США, где очень сильно считают экономику, одноэтажное? Ну ладно, 2-3 этажное?
Google
ТСО у многоэтажек выше, ибо ещё и дороже обслуживание. Подача воды, лифты…
Глупости. Для подачи воды в многоэтажку требуется не больше коммуникаций чем для оной же для коттеджного поселка.
А учитывая необходимость станций водоочистки там совсем не все однозначно.
Что касается электричества и связи, то многоэтажки выигрывают однозначно.
Подумайте, почему США, где очень сильно считают экономику, одноэтажное? Ну ладно, 2-3 этажное?
Вот один из вглядов на эти причины.
https://urban.hse.ru/suburbanization
Есть и другие. И «более дешевый» во всех случаях не фигурирует практически никогда кроме цены земли.
В коттедже делается колодец, туда гибкий шланг и насос до бака. В доме — локальный водогрей на втором этаже, причем основной нагрев — от солнца. На 9ый этаж вы так воду не загоните, там совсем иные мощности нужны. И надежность иная, ибо если сбоит подача воды для конкретного коттежда — это не стращно, можно пару дней и вручную натаскать. А вот если отрубилась подача воды в многоэтажку — это ласты. И прежде всего — для использования туалета. :-)
Не пробовали жить в многоэтажке без воды?
Не пробовали жить в многоэтажке без воды?
Вы какой-то восторженный юноша из розовой страны.
Так вот я вас просвещаю. Воды приемлемого качества в местности может тупо не быть. То есть вообще, никогда. И колодец никак не решает проблемы приведения воды к нужному состоянию (например по жесткости).
Стоимость бурения сотни метров скважины вы в курсе?
Сводим это на типичный 1000квартирный дом или аналогичный же поселок коттеджей.
Стоимости погуглите.
И… Нагрев от солнца… Ну да, зимой… на широте Питера или даже Нью-Йорка… Не смешно.
Так вот я вас просвещаю. Воды приемлемого качества в местности может тупо не быть. То есть вообще, никогда. И колодец никак не решает проблемы приведения воды к нужному состоянию (например по жесткости).
Стоимость бурения сотни метров скважины вы в курсе?
Сводим это на типичный 1000квартирный дом или аналогичный же поселок коттеджей.
Стоимости погуглите.
И… Нагрев от солнца… Ну да, зимой… на широте Питера или даже Нью-Йорка… Не смешно.
Угу, летом на широте на Питере используется солнечный нагрев воды. Градусов на 15-20 нагревает.
И не строят коттеджные поселки там, где нет воды. Лес растет — значит водоносный горизонт довольно близко (до 10 метров глубины). Артезианские скважины больше нужны для того, чтобы был естественный напор.
По жесткости вода и в Москве не приведена «к нужному состоянию». Ибо вполне жесткая.
И не строят коттеджные поселки там, где нет воды. Лес растет — значит водоносный горизонт довольно близко (до 10 метров глубины). Артезианские скважины больше нужны для того, чтобы был естественный напор.
По жесткости вода и в Москве не приведена «к нужному состоянию». Ибо вполне жесткая.
Опишу проект на хабре — кину ссылку.
Было бы интересно почитать )
А идеально — вместо 5 разработчиков нанять одного и платить ему в 4 раза больше.
Не поможет.
Просто потому что количество таких людей, чья производительность выше обычного разрабочика в 5 раз, строго ограничено. И их не то что в 5 раз меньше, их в 500 раз меньше чем обычных разработчиков.
И тем не менее, на одну компанию, которая захочет пойти этим путем, — точно найдется. :-) По опыту проверено. Более того, метод «Бригады главного хирурга» обеспечивает довольный быстрый рост в мастерстве подмастерьев.
Потому что на 500 обычных разработчиков — 50-100 могут стать гуру, если их будет учить гуру.
Потому что на 500 обычных разработчиков — 50-100 могут стать гуру, если их будет учить гуру.
Очень здорово, что Вы написали вступительный абзац, потому что в нем явно обозначен контекст — для применения указанных правил, нужно их уметь применять. Вы научились за несколько лет, но в статье выдаете «готовые» решения. Обратите внимание, перечисленные причины могут быть взаимоисключающими: задача интересная, задача сложная, задача простая, задача скучная и т.п. А решение предлагается одно — делегировать. На мой взгляд, Вы можете замечательно развить идею если подробнее напишите, как научиться делегировать правильно. Успешно делегировать это действительно круто. Вы интересно пишите, удачи.
Спасибо!
Про раскрытие темы — поняла, подумаю, напишу.
Озарение как и что нужно делать, чтобы правильно отдать задачу, у меня было после просмотра занятия про делегирование в школе Стратоплан, к сожалению не нашла у них в блоге соответствующую статью.
Из интересного и направляющего в эту сторону также есть Михаил Ефимович Литвак «Командовать или подчиняться», у него тоже описано как правильно делегировать задачи.
Про раскрытие темы — поняла, подумаю, напишу.
Озарение как и что нужно делать, чтобы правильно отдать задачу, у меня было после просмотра занятия про делегирование в школе Стратоплан, к сожалению не нашла у них в блоге соответствующую статью.
Из интересного и направляющего в эту сторону также есть Михаил Ефимович Литвак «Командовать или подчиняться», у него тоже описано как правильно делегировать задачи.
Понимаю Вас, «озарение» — это некая точка, в которой «количество перешло в качество». Естественно это происходит после очередной порции информации (знаний, понимания). Я хочу сказать, что совсем не обязательно именно это занятие такое. Просто у Вас оно послужило спусковым крючком и заякорилось. Но если кто-то пройдет это занятие еще не будучи готовым к делегированию он подумает «что за ерунда?».
Я, кстати зашел к ним по Вашей ссылке, и то же не нашел.
Ну и там, у меня в комменте опечатка, которая не дает мне спокойно спать. Вы интересно пишете. )
Я, кстати зашел к ним по Вашей ссылке, и то же не нашел.
Ну и там, у меня в комменте опечатка, которая не дает мне спокойно спать. Вы интересно пишете. )
Возможно проблема выбора делегировать или нет возникает из-за конкуренции на решениях / архитектуре / коде. Отдать код другому означает потерять над ним контроль и, вероятно, со множеством последствий.
Был случай, начали разрабатывать систему, спроектировали предварительную архитектуру БД, интерфейсы хранимок, передали разработчику на реализацию. Закончилось тем, что от предварительной архитектуры не осталось ровным счетом ничего.
Однако делегировать все же надо хотя бы потому, что надо же как-то распараллеливать работу по работникам. Вопрос только в том, как это сделать правильно. И лучше заменить термин делегирование на распределение заданий.
Был случай, начали разрабатывать систему, спроектировали предварительную архитектуру БД, интерфейсы хранимок, передали разработчику на реализацию. Закончилось тем, что от предварительной архитектуры не осталось ровным счетом ничего.
Однако делегировать все же надо хотя бы потому, что надо же как-то распараллеливать работу по работникам. Вопрос только в том, как это сделать правильно. И лучше заменить термин делегирование на распределение заданий.
Кадры решают всё
Для хорошего делегирования нужны те, кому это реально можно делегировать. Все эти правила хорошо работают когда есть люди способные развиваться, вникать в проект и становиться полноправными участниками, а не ходить как болванчики с вопросами о каждой запятой и фразами «мне не понятно и это слишком сложно» работая уже не один месяц.
Очень важный момент, хорошо, что вы о нем написали. К сожалению есть люди, которые совсем не готовы ни с чем разбираться сами, и действительно спрашивают каждую запятую, при этом не ясно, если человек шел в проект без документации (я на собеседовании об этом старалась говорить) или с провалами в ней, то почему он не может прочитать и разобраться по коду. Фраза «Это слишком сложно» вообще убийственная, хорошо, что человек об этом говорит, это звоночек что ему нужно дать задачу попроще, но возникает вопрос, а будет ли это для него когда-нибудь понятно. В общем люди очень разные и уметь понять кому что давать и как — очень важный навык, который к сожалению нарабатывается небыстро.
Хорошая статья. Мне это очень близко. Я умирала над проектами, а мои сотрудники были в расслабленном состоянии или делали что-то неважное. Хорошо, что продлилось это не долго. Для себя определила 2 вещи:
1. Нужно просто сделать это. Просто сменить у задачи ответственного. Сказать — это твоя задача. Если трудно решиться и не хочется этого делать — нужна только секунда, чтобы сказать эту фразу, просто скажи её. После чего нужно убедиться, что задача понятна — но тут как обычно.
2. Делегировать правильному человеку. Даже если с меньшим опытом, но он умеет находить решение, пусть и сильно дольше, чем ты, пусть не так «идеально», как ты. Как проверить — дать несколько своих задач: справляется — давать больше, на усложнение. Не справляется — поручить другую работу или расстаться — здесь тоже нужна решимость. У наших молодых руководителей сейчас 2 основные проблемы: неумение делегировать и боязнь принимать кадровые решения.
1. Нужно просто сделать это. Просто сменить у задачи ответственного. Сказать — это твоя задача. Если трудно решиться и не хочется этого делать — нужна только секунда, чтобы сказать эту фразу, просто скажи её. После чего нужно убедиться, что задача понятна — но тут как обычно.
2. Делегировать правильному человеку. Даже если с меньшим опытом, но он умеет находить решение, пусть и сильно дольше, чем ты, пусть не так «идеально», как ты. Как проверить — дать несколько своих задач: справляется — давать больше, на усложнение. Не справляется — поручить другую работу или расстаться — здесь тоже нужна решимость. У наших молодых руководителей сейчас 2 основные проблемы: неумение делегировать и боязнь принимать кадровые решения.
Принцип делегирования стоит применять и как способ мотивации, но для этого нужно уделять огромное внимание отбору талантов. Осознанность — главная ценность, которую несет в себе сотрудник. Едва ли можно ее развить, если изначально она отсутствовала. Но ее задатки и очевидные проявления даже на этапе собеседования можно/нужно отследить.
Я считаю, что каждый работник, который хочет двигаться вперед, должен осознавать в перспективе делегирование полномочий. Без этого никак.
Sign up to leave a comment.
Грабли при делегировании, на которые я наступила