Типичный инженер, поставленный в условия абсолютной свободы для выполнения поставленной задачи, способен, как максимум, сказать, что задача невыполнима и привести очень хороший набор доказательств своего утверждения. Требуется менеджер, который разобьёт задачу на простые небольшие куски, невыполнимость которых инженер доказать не сможет.
И вот тут начинается интересное: человек, который делит задачу на удобоваримые для инженера куски, как правило, либо ничего не понимает в предмете, либо совсем ничего не понимает в предмете. Если очень повезёт, то когда-то, лет десять назад, этот человек сам пытался быть инженером и ещё чего-то помнит.
Таким образом, в больших проектах получается то, что мы обычно имеем: софт не стыкуется с железом, железо не лезет в стойки, стойки не проходят в двери и т. д.
Есть ли выход? Вопрос пока открытый...
Автор: Игорь Обухов.
Интересное...
Комментарии:
Tolik said:
Творчеству полезны тупики
Боли и бессилия ожёг
Разуму и страху вопреки
Душу вынуждает на прыжок
(с) И. Губерман
С другой стороны - дать инженеру просто обосновывать невыполнимость любой задачи - тоже неверно.
booter said:
... и тут приходят консультанты...
arkanoid said:
Есть. Хороший менеджер должен иметь достаточное представление о вопросе. Людей, не разбирающихся в технической специфике, нельзя допускать до непосредственного технического руководства. Правильный технический менеджер - это тот, кто возьмет бизнес-требования от административного руководства и переведет их на технический язык для инженеров, а также донесет в обратном направлении необходимую информацию, если надо. А если человек торговал резиновыми сапогами, а потом его как "хорошего менеджера" отправили в IT, ничерта из этого не получится. Только Ашманов считает, что это не так, по-моему ;-)
Igor Obukhov said:
Анатолий, цитата -- супер!
arkanoid, вы знаете хотябы одного человека, который одновременно нормально разбирается в: современном корпоративном ПО, современных серверных ОС, современных СУБД, взаимодействии ОС, СУБД и этого ПО, серверных решениях ведущих вендоров, коммуникационных решениях ведущих вендоров, шкафах и стойках для оборудования, актуальных СНиП, СанПИН, ГОСТах, ПУЭ, отделочных материалах, технологиях производства строительных работ, системах охлаждения, системах энергоснабжения, системах пожаротушения и соответствующих пожарных нормах и правилах, системах видеонаблюдения и контроля доступа?
А ведь по факту решения во всех этих областях приходится принимать _одному_ человеку. Может ли один человек принять квалифицированные решения во всех этих областях? Да еще и разжевать инженерам, что именно они должны сделать?
Tolik said:
2 arkanoid
Почитай эту книгу
https://seoded.blogspot.com/2018/05/blog-post_42.html
Там как раз про менеджера , который НИЧЕГО не понимал в ИТ. Но поднял IBM из могилы, куда её загнали разбирающиеся в технике предшественнике.
Менеджер вообще ничего не должен переводить ни на какой язык, он должен найти правильных людей, поставить их на правильные места, расставить им правильные приоритеты и обеспечить возможность работать. Дальше они всё сделают сами. И процесс этот примерно одинаков, что в торговле сапогами, что в запуске космолета на Луну.
А для перевода - нужны отдельные специалисты (у нас они аналитиками называются, но могут и как-то по-другому). Они к управлению отношения не имеют.
Вот как раз опасен менеджер, который (уже обладая властью) лезет в конкретные вопросы (уже утратив квалификацию), но не может данной проблемы осознать. В околотехнической среде это встречается особенно часто.
Alexander Kupriyanov said:
ППКС "Вот как раз опасен менеджер, который (уже обладая властью) лезет в конкретные вопросы (уже утратив квалификацию), но не может данной проблемы осознать. В околотехнической среде это встречается особенно часто." Неоднократно видел, извлек для себя уроки:
При переходе из "инженеров" в "менеджеры" целенаправленно искоренял у себя стремление влезть в собственно технические вопросы - в них должен разбираться правильно мотивированный инженер или же его следует уволить/перевести в клерки...
Менеджер не способный мотивировать... распределить задания... сформировать рабочую группу... ... на следующих ступенях - не обладающий видением (vision)... ... - не должен быть менеджером.
Vladislav Artukov said:
Задача.
Топ должен ее решить. У него есть относительно немного ресурсов - времени, денег, людей. За пределы ресурсов выбиваться сильно - нельзя. А вот экономить - можно, даже нужно, поскольку заметный процент от экономии падает на личный счет топа.
Топу кажется, что задачу решить можно в пределах бюджета. Не спрашивайте, почему ему кажется вот так, а не эдак. Это vision, и за это он получает деньги.
Сам топ не может внятно сказать, что такое vision и откуда оно берется. По-русски же это определяется просто - "в голову стукнуло".
Топ идет к аналитикам....
vitalikovalev said:
Если задача для инженера непонятна и лишена смысла, то первое, что сделает инженер - это докажет ее несостоятельность. Глупый менеджер поделит всё на куски и на каждом куске убедится в несостоятельности задачи. Умный менеджер приложит усилия к тому, чтобы задача для инженера стала выглядеть состоятельной, целостной и логичной. А потом начнет вместе с инженером делить пирог.
maximus said:
Абослютно согласен с двуму предыдудущими ораторами. Менеджер не должен знать и\или разбираться в технических вопросах.
Что менеджер действительно должен так это разбираться в людях, и взять на проект тех, кто его сделает, или создать им такие условия чтобы они таки сделали.
vylkas said:
Зачастую менеджер и не делит задачу на кусочки - это делает инженер. Задача менеджера - задавать правильные вопросы, которые помогут инженеhe начать думать в нужную сторону.
leonidas said:
собственно о чем речь в этом посте?
о том как правильно построить сложный инфраструктурный обьект( например ЦОД) или о том как этим руководить? один инженер не в состоянии расчитать ЦОД, всегда работает команда как минимум из 2-частей, например начинка ЦОД и инфраструктура (сферы слишком разноплановые чтобы один человек смог их свести воедино в своем лице). нужен ли над ними менеджер для руковождения? функции управления может взять на себя один из членов команды. Причем по собственому опыту знаю, что зачастую "верх" берут инфраструктурщики, поскольку фокус внимания проходит от постановки задачи бизнесом через сервера и активку к инфраструктуре. Затем волна может еще раз прокатиться туда-сюда для утрясания возникших разногласий, но окончательная фаза расчетов все равно в инфраструктуре. Как ни странно, смысл ЦОД - предоставить вычислительные мощности, но управляющая роль зачастую за инфраструктурой, именно она приземляет и делает реальными прожекты.
Кто всем этим должен управлять? в первую очередь человек, который может подняться выше своей узкой задачи, и консолидировать остальных членов команды, взять главенствующую роль. Будет это менеджер или инженер, уже не так важно.
Igor Obukhov said:
2 leonidas:
Речь не обязательно о большом проекте. Однажды я такое наблюдал на проекте "внедрения" Outlook'а. Задача: перетащить почту на аутлук. Заказчик оплачивает все, что исполнитель сумеет обосновать как необходимое. Бюджет -- почти неограниченный -- сотни миллионов рублей общего ИТ-бюджета у заказчка и внедрение аутлука как приоритет номер один, т.е. на это могли быть потрачены 99% ИТ-бюджета.
Что говорит первым делом инженер, которому это поручают? Правильно. "Это невозможно". Когда ему объясняют, что вообще-то аутлук внедрен много где, он говорит "но кто так делает? заказчик должен это, то и вон то".
Хотя с ЦОДами так тоже бывает. Одна компания клялась и божилась, что они умеют серверные под ключ. Сформулировал наши требования, попросил дать хотябы примерно конфигурацию оборудования, какие кондиционеры, какие чиллеры, какие шкафы, какие ИБП будут... Люди ушли в себя на две недели, выдали конфигурацию ИБП (предложили, для тех кто понимает, внутрь серверной ставить батареи на стеллажах открытых), все. Ни кондиционеров, ни шкафов они не осилили.
leonidas said:
2 Igor Obukhov
Ну бракоделов и непроффесионалов в любой области хватает.
Я попытался ответить, осветив ситуацию "в принципе". Хороший инженер должен знать свою область и знать где она кончается :). И уметь совершать переход в другую область. Путем подключения другого инженера, подрядчика, менеджера. Сомневаюсь что любой российский сист. интергратор сможет самостоятельно решить все проблемы построения полнофункционального ЦОД. тоТот же APC? включив в свое решение кондиционеры, благополучно заOEMил их у какой то фирмы и на монтаж привлекает внешнего подрядчика.
Проффесионализм в таких областях проявляется именно в интеграции своих и чужих навыков.
0 коммент.:
Отправить комментарий
Ваш комментарий появится в блоге после проверки администратором