gifts2017

Чем меньше воинов и лучше они подготовлены, тем ближе победа

Опубликовал Александр Венгер (venger) в раздел Сообщество - О жизни

Наш ответ Чемберлену: «Один в поле не воин или статья про состав команды для проекта» ( http://infostart.ru/blogs/1054/ )

 

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

 

Цитата: «Для начала немного истории. 1с программные продукты до 8 версии были таковыми, что их мог поддерживать один человек. Этот человек рассматривался как очень грамотный пользователь, платформа, как известно, не является средой объектно-ориентированного программирования. Это некий конструктор, из которого можно получить многое, но в рамках заложенных известных правил.»

 

Странное утверждение, совершенно ни как не доказанное и без основательное. Начнем с того, что если это «грамотный пользователь» - то и семерку он поддерживать на должном уровне не смог бы, если речь, конечно, не о типовых обновлениях бухии. Ведь мы говорим не столько об обновлениях или исправлениях печатных форм, а о реальных доработках и переработках кофигураций, не говоря уже о создании проектов с нуля. Или отсутствие «объектно-ориентированного программирования» на платформе семерки автоматически переводит программиста семерошника в разряд пользователей? Или зададим такой вопрос автору: «Тогда кто же были те, кто писал свои программы (и не только на 1С) до появления парадигмы ООП?» А фраза: «Это некий конструктор, из которого можно получить многое, но в рамках заложенных известных правил.» Т.е. появления ООП сразу снимает все заложенные правила и дает безграничную свободу? Так ли это на самом деле. Или возможно автор мало понимает суть ООП? Ведь ООП это лишь способ оформления, по сути, алгоритмов в коде программы, для удобства разработчиков. И это делает восьмерку более (по идее) эффективным средством разработки и отладки приложений, что должно по идее сократить трудозатраты, а соответственно, и количество разработчиков, а не наоборот, как далее пытаются утверждать в статье, но об этом ниже. Ибо ООП для этого и создавалось, напомним автору. Для облегчения труда программистов, облегчения моделирования, облегчения отладки, возможности создавать более надежные приложения, облегчения сопровождения, облегчения совершенствования, масштабирования и развития приложений, а также более эффективного повторного использования кода, опять же для уменьшения трудозатрат программистов.

Также хотелось бы отметить, явную подмену понятий в этом первом же абзаце, т.е. семерка, получается, – это некий ограниченный конструктор, требующий знаний только пользователя, а восьмерка – это некий супер-инструмент для супер-программистов, обещающий заоблачные выси, но как дальше оказывается, еще и требующий гораздо большего количества специалистов для поддержания и развития системы, да и еще так и непонятно какие именно выси он обещает, кроме раздутых бюджетов. Но об этом позже:-)

 

Идем дальше:

«1С -ники как пчелки поддерживали системы разной сложности – больше конечно для мелких фирмочек, поскольку действительно большие объемы информации семерка не выдерживала. Истории про то как отчетик формировался всю ночь, чтоб утром посмотреть… Ну в общем, фирмочки росли, росли и 1С решила выпустить новую платформу, для подросшего мелкого и среднего бизнеса.»

 

Так ли это? Скорее жажда прибыли, толкнула фирму 1С на создание восьмерки, а не забота о мелком и среднем бизнесе. Ведь если он «подрос», то перешел в разряд крупного. Такому, возможно, восьмерка и не помешает (да и переход на восьмерку по денежным вливаниям, особенно во время кризиса, под силу как раз крупному бизнесу). А вот мелкому, да и среднему, вполне можно остаться на семерке, дабы не раздувать расходы свои. А тем временем поддержка семерки фирмой 1С всячески ограничивается и фирма 1С всячески пытается «заставить» этот мелкий и средний бизнес таки перейти на восьмерку и затратить еще средства, которых итак у него не хватает. И это забота? Хм… Странная забота…

Еще один момент, идет явное манипулирование сознанием обывателей. Ведь по абзацу и словам видно, что пытаются внедрить следующий стереотип в сознание: «если Вы используете семерку, то у Вас фирмочка (так пренебрежительно), а если восьмерку – то Вы выросли и являетесь представителем подросшего мелкого и среднего бизнеса». Хм… Ничего не напоминает?:-)

 

Идем дальше:

«Только вот принципы работы 1Сника остались прежними. Одинокий волк чего то там поддерживает.»

Не будем вдаваться в конкретные кофигурации фирмы 1С, мы ведь говорим о платформе восьмерки. И откуда такое безапелляционное мнение, что на семерке всегда и везде разрабатывал и поддерживал «одинокий волк» - есть куча проектов, где работали большие группы программистов, а об одновременной работе над MD’шкой нескольких программистов (связка 1c – gcomp – cvs) мы скромно промолчим, также как скромно промолчим о 1С++ (дающей нам парадигму ООП в семерке):-)

 

Идем дальше:

«Универсальность она конечно хороша. Когда надо сэкономить. Надо чтоб человек и пользователя разной степени адекватности понял, и ТЗ написал и архитектуру системы знал, и код писал, и работы сдал и того же пользователя научил и доказал что он сделал то что доказывали.

И получается как в белом солнце пустыни.

Одна жена любит, одна одежду шьет, одна пищу варит, одна детей кормит. И все одна? - Ничего не попишешь. - Тяжелооо. - Конечно, тяжело

Не будем рассуждать, как жена выполняет свои обязанности, когда работает как дом быта, просто представим необходимые познания и навыки 1Сника на хорошем таком проекте, где надо не просто пару отчетов дописать.»

В заключение скажу еще одно, во всех этих абзацах нам (без доказательств, без конкретной информации) навязывается мысль, что для семерки нужно дописать «пару отчетов» и это простой примитивный конструктор, который под силу одному пользователю, для мелких фирмочек, серьезным бизнесом не занимавшихся. А вот восьмерка – это верх совершенства. Что смахиваете на простую и примитивную рекламу и пиар восьмерки, не более того. Хотя смешно тут то, что семерка, которая удовлетворяла худо-бедно потребности бизнеса не один год, если судить по этой статье (получается что для семерки нужно дописать пару отчетов и это простой примитивный конструктор, который под силу одному простому пользователю, для мелких фирмочек), просто верх совершенства по соотношению трудозатрат, эффективности и результатам :-) Где вы найдете такие системы (базы данных), где достаточно дописать пару отчетов и один пользователь способен поддерживать и развивать систему на должном уровне, особо не ударяясь в программирование, проектирование, тестирование и т.п.? Оказывается такое было! Это была семерка, а мы проглядели:-)

Дальше в статье перечисляются «необходимые познания и навыки 1Сника на хорошем таком проекте, где надо не просто пару отчетов дописать». Для начала отметим, что априори предполагается, что «хороший такой проект» возможен только на восьмерке, а не семерке все до этого просто клепали по пару отчетиков на фирму. Смехота, да и только:-) Также отметим, что то, что будет перечислено (я кратенько перечислю, не пугайтесь), относилось к области программирования еще за долго до того, как появился вообще такой класс программ как 1С, и тем более задолго до того, как появилась восьмерка. Но зачем это знать автору? Ведь его дело запудрить мозги покупателям и получить прибыль:-)

Итак, перечислю все-таки кратенько:

Человек должен хорошо понимать предметную область разработки.

Человек должен знать архитектуру готового продукта.

Написание кода в больших количествах. То есть решение вопросов алгоритмирования и отладки.

Проверка того что сделано, прием работы.

Обучение клиентов, написание инструкций пользователям, ответы на телефонные звонки.

«Вывод конечно однозначный. ТЯЖЕЛО одному все это. Быть аналитиком, архитектором проекта, кодером, тестировщиком, консультантом.»

 

Скажите мне, с какого бодуна это относится сугубо к восьмерке? Или еще лучше, с какого бодуна это относится только к продуктам фирмы 1С? Это извечные проблемы извечных проблем:-) Извините за тавтологию:-)

Не будем расписывать выводы, которые делаются по этим пунктам, т.к. суть не в том, какие они, а в том, что автор намеренно создает впечатление крутизны, серьезности и масштаба проектов на восьмерке, совсем забывая, что тоже относится и к семерке, да и к любым системам, а 1С тут никаким боком не лежало, в принципе то:-) Это было до нее, это будет и после нее:-)

Тем более, что выводов то никаких по сути и нет, т.к. цель статьи не дать ответы, а раскрутить и распиарить восьмерку, усыпив бдительность пользователей и создав иллюзию панацеи от всех бед.

Мы же под конец приведем несколько мыслей и ссылок на размышления, касающихся поставленных в статье вопросов, причем еще раз отметим, что вопросы эти касаются всех областей программирования, а не только программ 1С:Предприятие.

 

«Если бы единственной разницей между программистами была продуктивность, вы могли бы прийти к выводу, что можно заменить одного действительно хорошего программиста пятью простыми. Очевидно, так не получается. А все потому, что закон Брукса гласит: «Подключение новых людей к запоздавшему проекту еще больше его задерживает». Единственный хороший программист, работающий над единственной задачей, не имеет накладных затрат на координацию действий или взаимодействие с коллегами. Пять программистов, работающих над той же задачей, должны согласовывать свои действия. Это занимает массу времени. Есть все-таки смысл держать команды, работающие над проектом, небольшими. На самом деле, человеко-месяц — это миф

«Истинная проблема работы посредственных программистов вместо парочки профессионалов в том, что сколько бы они ни работали над задачей, они никогда не создадут такого продукта, какой могут создать профессионалы.

Пять Сальери не напишут «Реквием» Моцарта. Никак. Даже если они будут работать над ним сто лет. »

«Посредственность никогда не достигает тех высот, на которых спокойно парит профессионал. Количество оперных див, способных взять высокую ноту f6 в моцартовской «Королеве Ночи», так исчезающе мало... Но «Королеву Ночи» просто невозможно исполнить, не пропевая эту знаменитую f6.»

http://russian.joelonsoftware.com/Articles/HighNotes.html

«Создание ПО -- это не промышленное производство. В 1980-х годах все были запуганы тем, что японские компании, выпускающие ПО, создавали "фабрики программ", которые должны были выдавать высококачественный код на сборочном конвейере.Это ничего не значило тогда, не значит и сейчас. Заталкивание большого количества программистов в одно помещение и выстраивание их в аккуратные ряды не особо помогло в борьбе с количеством ошибок.»

«Мастерство, конечно, невероятно дорого. Вы можете его себе позволить только если вы разрабатываете ПО для массовой аудитории. Жаль, но внутренний софт для управления персоналом, разработанный в страховой компании, никогда не достигнет этого уровня мастерства, потому что там просто недостаточно пользователей, чтобы окупить дополнительные затраты. А для небольшой компании, выпускающей ПО, этот уровень мастерства - это как раз то, что восхищает пользователей и обеспечивает долгосрочную конкурентоспособность, поэтому я потрачу время и сделаю это правильно. Потерпите меня.»

http://russian.joelonsoftware.com/Articles/Craftsmanship.html

«Одной из наиболее важных составляющих успеха Microsoft было стремление Билла Гейтса нанимать только лучших. Если вы нанимаете только отличников, говорил он, они, в свою очередь, будут нанимать отличников. Но если вы нанимаете хорошистов, они наймут троечников, и тогда пиши пропало.»

http://russian.joelonsoftware.com/Articles/CommandAndConquer.html

 

Так что рецепт простой: старайтесь делать компактные и минимально достаточные по численности команды лучших специалистов, которых смогли найти, и создайте им такие условия труда, чтобы они хотели работать. А затем дайте им возможность работать - «не будите программиста» и поменьше слушайте всякой рекламной шелухи:-)

 

См. также

Подписаться Добавить вознаграждение

Комментарии

1. Александр Венгер (venger) 05.05.09 17:25
(0) Холивар фореве:-) Покой нам только снится:-)
2. Игорь Белышев (biv75) 05.05.09 17:45
Грамотно, аргументировано, по существу
3. beigka (beigka) 05.05.09 18:05
вы уж извините, я не думала семерошников обижать. тема моей статьи была - обратить внимание людей, занимающихся разработкой ПО или заказчиков проектов к тому что команды обычно недоукомплектованы, что приводит к рискам и снижению качества продукта.
я не продавец и не рекламщик, я внедренец.
но за то что прочитали и свое мнение сказали - спасибо.
4. larissa builova (larisab) 05.05.09 18:19
Если заглянуть в профайл автора статьи http://infostart.ru/blogs/1054/ и почитать первую ее статью и комменты, становится ясно, что вести речь о чем-то глобальном нет смысла:))). Цели другие у статьи, в конце они и сформулированы: "На ком будем экономить?", и всеее:))). ИМХО.
5. larissa builova (larisab) 05.05.09 18:28
+ 4 в кризис тестировщиков и консультантов сокращают:((
6. beigka (beigka) 05.05.09 18:44
2 larisab (4) пытаться объять не обьятное не хочу.
не сильно приятный коментарий от вас...
7. larissa builova (larisab) 05.05.09 19:01
(6) Простите, не хотела обидеть, но такое впечатление сложилось у меня, лично у меня (ИМХО).
8. Александр Шишкин (Шёпот теней) 05.05.09 21:24
с таким же успехом можно написать и критику на критику статьи beika, господином Венгером ... пока нет Цели и ОбъЁма работ и неизвестно количество отпущенных Ресурсов на вЫполнение то обе эти статьи можно считать правильными и хорошими ... всЁ зАвисит от точки отсчЁта ...

.. и если желание заработать "+" для одного это и нормально то для другого заводить новую ветку для обсуждения мне кАжется нЕ крАсивым ... тема то с бОрОдОй ... настолько старая и столько РАЗ обсуждаемая, что невероятно пытаться еЁ ещЁ рАз обсуждать сЕрьЁзно ...

... трАвА зЕлЁнАя а нЕбО сИнИе ...

...воооОооотмОёмнЕние....
9. Олег Пономаренко (O-Planet) 05.05.09 21:31
Удивлен, блин. Вот такое и пиши... ;)
10. Александр Рытов (Арчибальд) 06.05.09 07:43
(3)>я внедренец...
Вот об этом и шла речь в той статье. О том, что злые дяди не хотят оплачивать накладные расходы внедренца, который знает заранее, что будет внедрять, а цели и задачи автоматизации для него вторичны.
NatalyaVP; motogon; +2 Ответить
11. Lomok (lomok) 06.05.09 08:19
А это только у меня одного шрифт такой ку..вый?

"Так что рецепт простой..." - где то читал (не могу щас найти) что команда программистов это как улей с пчелами. И управлять ей надо соответствующе :)
13. Александр Венгер (venger) 06.05.09 12:38
(3),(6) beigka, воспринимайте это как веселую игру в "столкновение мнений", не принимайте близко к сердцу:-) Более того, рад, что Вы не стесняетесь и пишите статьи - это хорошо! А критика - это самое ценное, что можно получить, ибо даже проигрывая в споре - Вы выигрываете, на самом деле, т.к. получаете живую, актуальную информацию на интересующие Вас темы, знакомитесь с аргументами других точек зрения, начинаете видеть проблему более многогранно...
NatalyaVP; vinsentfire; motogon; +3 Ответить
15. Александр Венгер (venger) 06.05.09 13:23
(12), (14) Я скинул это к нам в рабочую е-mail конференцию, пусть манагеры почитают, позлятся....:-)))
16. Sheridan (WKBAPKA) 06.05.09 14:51
относительно ООП хотелось бы добавить, что появление ООП это не только способ оформления алгоритмов, это новая парадигма, новая философия программирования...
17. Sheridan (WKBAPKA) 06.05.09 14:56
без команды внедрить УПП можно но будет очень долго ;)
18. Александр Венгер (venger) 06.05.09 15:08
(17) Команды бывают разные ;)
vinsentfire; gavril; +2 Ответить
19. beigka (beigka) 06.05.09 15:55
пчелиный рой - это бардак.
если ктото верит что рой - это клево и с этим можно работать, ну пусть работает. а я хоть вокруг себя разгребу...
20. Александр Венгер (venger) 06.05.09 16:10
(19) > пчелиный рой - это бардак.

Вы так плохо знаете пчел? ;) Жаль - у природы надо учиться ;)

З.Ы. Ту статью я не защищаю, просто если о пчелах, то там четкая организация;)
Borometr; vinsentfire; motogon; +3 Ответить 1
21. Александр Рытов (Арчибальд) 06.05.09 16:13
(19) Пчелиный рой - это объективная реальность. Ну, с элементом гротеска, конечно.
Если же радикального креатива не требуется, наведение порядка вполне возможно. Мед на 98% состоит из сахара, который делается отнюдь не пчелами.
22. Александр Рытов (Арчибальд) 06.05.09 16:17
(20) Нет, все правильно. В 19 подразумевается не сам рой, а связка рой - директор. Это бардак, ясное дело.
23. Александр Венгер (venger) 06.05.09 16:20
(22) Связка рой - директор, директор попадет в реанимацию от множественных укусов;) А вот связка матка - рой, это хоть как-то смахивает на аналогию. Т.к. в противном случае, по таким аналогиям может существовать связка рой пчел - медведь;) И в чем польза такой аналогии?;)
24. Александр Венгер (venger) 06.05.09 16:27
(22) +23, Кстати, аналогия пчеловод - рой пчел, как-то ближе к теме;-) И хде там бардак?
vinsentfire; +1 Ответить
25. Александр Рытов (Арчибальд) 06.05.09 16:31
(23)У директора достаточное количество средств защиты.
Матка же не взаимодействует с семьей, она в ней живет. В смысле, не живет вне семьи => не может противостоять ей.
26. Александр Венгер (venger) 06.05.09 16:34
(25) Аналогия неряшлива, пчеловод - рой, вот аналогия. А так не понимая процесс, им всегда плохо получается управлять. Пусти на пасеку хоть министра, он тоже дров наломает и скажет, что у пчел бардак ;)
NatalyaVP; vinsentfire; motogon; +3 Ответить 1
27. Александр Рытов (Арчибальд) 06.05.09 16:44
(26)Пчелы живут не только на пасеке, в том-то и проблема. На всех пчел пчеловодов не хватает. 8)
28. Sheridan (WKBAPKA) 06.05.09 17:09
как и во всем, все зависит от организатора... если проектный менеджер хороший, значит и команда будет работать хорошо, а если нет, значит нет :)
29. Александр Венгер (venger) 06.05.09 17:18
(28) Это лишь часть истины, если команда никакая, то никакой менеджер не поможет. Более того, что вкладывается в понятие "проектный менеджер хороший"? У нас в последнее время (я про Украину, например), вот в том же строительстве, хорошие архитекторы и проектировщики уже в пенсионном возрасте, а молодых специалистов нет или исчезающе мало, я про тот уровень, который должен быть, а не про пыль в глаза. И строят так, что (это мнение изнутри многих) волосы иногда дыбом встают, помимо того, что воруют на каждом уровне, откаты, отмывка денег, фиктивные бюджеты, работы, да и еще чиновники на лапу просят. И до кризиса квадратный метр по этому так дофига и стоил, при низком качестве строительства, хотя и материалы лучше стали и инструменты, и научно-технический прогресс вроде куда-то идет;)
30. Sheridan (WKBAPKA) 06.05.09 17:24
ну, это отголоски советской системы образования... откаты и взятки, это менталитет народа, не думаю, что в нашей стране в ближайшее время что то измениться к лучшему, некому менять, да тот же Кролик купленный с потрохами... а хороший проектный менеджер это как хороший руководитель, компетентный прежде всего, и хороший организатор... умение организовать работу, своевременно контролировать исполнение ну и умение общаться с людьми и находить общий язык + владение технологиями- это хороший проектный менеджер. А одному даже УТП внедрить качественно будет очень сложно и очень долго, т.к. затрагивается большое количество областей автоматизации, а во всем быть ассом мало кому удается...
31. Александр Венгер (venger) 06.05.09 17:32
(30) Я никогда не утверждал, что можно все и всегда в одиночку, но логика, что сто грузчиков разгрузит вагон быстрее десяти, не совсем адекватна в случае программирования, это раз. И все должно быть сбалансировано, и руководитель грамотный и команда грамотная и численность разумная, это два. Но это уже отдельный разговор;)
NatalyaVP; vinsentfire; motogon; +3 Ответить
32. Александр Венгер (venger) 06.05.09 17:34
(30) +31, а ну и инструменты соответствующие задачам, а не наоборот ;) Типа во все дырки эту восьмерку и УПП пихать;)
NatalyaVP; vinsentfire; motogon; +3 Ответить
33. vladsol c (vladsol) 06.05.09 22:34
Такое большое количество красивых цитат меня это обычно настораживает, все эти сравнения, конечно говорят о начитанности автора, но как-то от сути уводят.
А вцелом действительно крупный проект одному выполнить в сжатые сроки не возможно, нужно собирать команду. Максимум на проекте у меня была команда 5 человек, причем большая часть времени уходила на согласования и переговоры. И это совсем не "руками водить", приходиться практически каждый день "компилировать" проект в голове, чтобы принимать новые решения, так что мое мнение - один в поле не всегда воин, просто не устоялся еще регламент для 1с-ников по организации работы на крупных проектах. Вышло под новый год сценарное тестирование, вполне можно пробовать экстремальные подходы по организации работы на проектах, раньше отсутствие возможностей автоматического тестирования мне казалось серьезным препятствием.
А то, что количество программистов на проекте, совсем не обязательно приводит к сокращению сроков его выполнения и качеству, совершенно согласен. Бывает очень трудно объяснить «недалекому» клиенту, что «мы» выполнить проект быстрее не сможем и количество людей работающих на проекте на это не повлияет, что «мы» не вагоны подряжаемся разгружать.
34. Майкопчанин (Майкопчанин) 07.05.09 17:17
Я хотел одновременно и плюс и минус поставить :) , но система поддерживает только какой-то один знак. Оставил плюс...
Плюс за труд и попытку осмысления проблемы.
Минус за открытие Америки и изобретение велосипеда.
35. Александр Венгер (venger) 08.05.09 12:29
(27) Кстати, о пчелах (две ссылки - две страницы) Александр Гордон Диалоги (июль 2003 г.) Интеллект муравьёв:

http://fictionbook.ru/author/gordon_aleksandr/besediy_20_7_dialogi_iyul_2003_g/­read_online.html?page=1

http://fictionbook.ru/author/gordon_aleksandr/besediy_20_7_dialogi_iyul_2003_g/­read_online.html?page=2
36. Allexey (alex_4x) 12.05.09 12:57
мои пять копеек ;-)
лет этак много назад, когда только появилась 1С торговля 7.0 - чтототамписание на 1С вообще не считалось программированием. Программировали на Дельфи, на Си, на ФоксПро. Все было замечательно, программисты изучали алгоритмы сортировок, указатели на указатели, составные типы данных и читали Страуструпа в надежде влится в сообщество людей, понимающих зачем же все-таки нужна объектная модель и какие это сулит красоты в исходном коде программы. Надо заметить, что программирование было, как мне кажется, больше академической наукой, нежели суровой практикой жизни. Когда пишешь алгоритм расчета напряжений в кристалле или программу объемного моделирования поведения жидкости - как-то не особо задумываешься о человеко-часах, а думаешь о том, как вообще с точки зрения математики это посчитать - раз, и как эту модель с бумажки перенести и чтобы заработало - в компьютер - это два. Но бывали случаи, когда таких вот программистов математиков (или химиков, минерологов, геофизиков, физиков) привлекали для написания чего-то полезного для бизнеса. Тут начиналось самое интересное - поборов природную брезгливость к «тупым» задачам, осознав, что сделать это придется, хотябы даже ради денег - программист начинал создание своей собственной торговой / складской / бухгалтерской программы.
Вот где был полет мысли! Вот где новое значение получало всё, где каждое решение, даже не идеальное технически - было выстрадано и по своему гениально. Часто техническое совершенство расчетных механизмов скрывало полную некорректность модели, но тогда это считалось нормальным. А потом в России началась эра 1С. И те кто делают что-то на 1С уже по другому смотрят на процесс создания конечного продукта - решения для какого-либо вида бизнеса, используя платформу - всё больше и больше уходят от технических сложностей к идеологическим. А те, кто на САПе работают - так вообще предпочитают не писать новый код, а как-то очень хитро использовать готовые наработки, и этот подход, как показывает практика, живет и дает результаты... А к чему это я всё? тут вот говорят про команду и про то, что надо толи фактически иметь мало диверсифицированных и крутых во всём специалистов, толи иметь много но узкоспециализированных, крутых только в одном чём-то специалистов. Я вижу тут такие критерии оценки возможных плюсов и минусов:
Риски, Сроки, Стоимость. Риски - это и соотношение ожидаемого результата к полученному и неправильная первоначальная оценка сроков/стоимости и надежность последующей поддержки и зависимость от команды разработчиков. Если мы говорим о некой гипотетической команде из 1 человека, то понятно, что риск проекта будет велик. Зато никаких издержек на внутренние коммуникации, организацию и так далее. Если один и тот же человек и ставит задачу сам себе и сам её с заинтересованностью выполняет - отсутствует вероятность того, что запланированное вначале будет выглядеть совсем не тем что думали. Но в этом случае в идеале - этот 1 человек и есть владелец бизнеса, для которого он пишет систему и знает его (свой бизнес и свои потребности в автоматизации он на все 100%). Такое вот мало вероятно, и получается что хотябы на момент передачи "хочу" от владельца к этой команде из 1 человека существует вероятность того, что поймут они друг друга неправильно. Многие проекты проваливались только потому, что Владелец бизнеса договорился с Менеджером проекта и понадеялся, что Менеджер проекта Гуру и сам всё сделает абсолютно правильно, а Менеджер не справился, условно говоря. Если 1 человек будет одновременно думать «что надо сделать» и «как это надо сделать» наверняка он найдет внутренний компромисс, но вот устроит ли этот компромисс в конечном итоге заказчика ? Вопрос технических квалификаций 1 человека и его возможностей – тоже надо учитывать, невозможно знать и иметь опыт во всем. Теперь вариант большой команды, где каждый знает свою узкую часть, отвечает за свой и только свой участок и решения принимаются на основе мнений многих экспертов, а не одного Гуру. Тут всё тоже далеко от желаемого идеала. Казалось бы – вот они – специалисты в своих областях, знающие всё вдоль и поперек о какой-то специфичной материи, делегирование ответственности экспертам в предметных областях – ну какие тут могут быть ошибки или недочеты в постановке и реализации задуманного ? А получается что могут. Потому что по отдельности всё здорово, а вместе может не срастись. Насколько я понимаю, например у САПа основная проблема – как увязать между собой прекрасно отлаженные модули, которые по отдельности работают идеально, а вот при смешивании в условиях реальных потребностей – как-то уж очень сложно взаимодействуют. Ну и конечно, чем больше специалистов – тем дороже будет разработка, поддержка и всё остальное. Зато и заменить каждого специалиста в отдельности представляется более реалистичным, нежели одного супер-все-в-одном специалиста. И кажется мне, что нет ответа – что лучше и что хуже – маленькая или большая команда – при различных факторах чаша весов будет склоняться то в одну, то в другую сторону, и остановится где-то на «золотой» середине. Только в каждом проекте эта «золотая» середина будет на разных местах – от одного человека до бесконечности.


soulsteps; gaglo; Трактор; NatalyaVP; venger; +5 Ответить
37. Андрей (vinsentfire) 19.05.09 00:21
Мда, сермяжная правда жизни:)
38. Андрей (vinsentfire) 19.05.09 00:30
Просто видел свооими глазами, как один человек пришел и заменил целую команду, так и еще сделал то, что им так толком и не удалось и в более короткие сроки. Просто пришел и сделал, без лишних разговорив и телодвижений. Где нужно убедил, где нужно расспросил и решил как лучше и т.д.
39. Александр Венгер (venger) 19.05.09 11:16
(38) Бывает и такое, но редко:-)
40. Денис Д (Alice) 26.05.09 13:34
"без команды внедрить УПП можно но будет очень долго ;)"
а с командой порой еще дольше...

- а за неделю управишься?
- ну, можно...
- а за две?
- нет, барин, тут помощник нужен.
(с)
41. evgen1977 (musatov1c.ru) 11.11.11 22:18
(38) vinsentfire, вы правы и это подтверждает слова автора. Но как мало таких людей. И как самому стать таким? Вообще не понятно. :(
Для написания сообщения необходимо авторизоваться
Прикрепить файл
Дополнительные параметры ответа