Собственно можно ли руководить группой программистов, не умея программировать?

Знаю, что был тренер по плаванию, не умеющий плавать. Готовил чемпионов :)

В конфигуратор не лазию, не лазил и не собираюсь.

Чтобы хотя бы понимать что из чего как там и откуда. Чтобы оценить качество и ресурсы. Должен.

Но должен хорошо в предметной области ориентироваться.

(0) не правильный вопрос. Правильный вопрос:

А должен ли руководитель группы разработки 1С знать 1С?

Должен ли руководитель что-то уметь? Конечно нет. Руководитель должен руководить.

кому должен уточните?

как можно руководить процессом не имея понятия, как это процесс в принципе "проводится" ?

(1) Я про руководителя группы разработки, а не про руководителя проекта!

С РП все понятно:
Вчера к нам пришел РП по УПП.
Первый его вопрос был - что такое УПП?
Я ответил - Что это такая типовая конфигурация 1С.
Второй вопрос был - И как его внедрять?
Я ответил - вначале заполнить справочники, потом вводить документы ;)
Третий вопрос был - Сколько тебе нужно времени, что бы все это сделать?

Я в шоке!

Что бы чем то руководить, нужно уметь руководить.

В принципе

Лишь-бы руки были позагребущее и водить ими умел. Эта должность для пробивания и выбивания. Лучшие претенденты из бокса в руководители проектов приходят :) Зачем им что-то знать?

А хороший

Зачем?

Собственно можно ли руководить группой программистов, не умея программировать? нет

Должен ли руководитель группы разработки 1С уметь программировать 1С? нет

Назначить подчиненным з/п отстатыщ и можно не париться

хотяб знать чем Процедура от Функции отличается

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

(8) на моей памяти был директор, звонит
- У нас сеть не работает. Сколько тебе надо минут, чтобы все починить?

(0) Должен кому?

(17) для этого можно иметь техконсультанта, который лапшу с ушей снимать будет...

(14) То есть как нет, когда я знаю примеры что да.
Причем много примеров, и весьма успешных.
Вообще не умея программировать.

(0) Страну уточни.

(0) Все зависит от того, насколько у него развита интуиция в качестве подобранных им кандидатов на программиста.

В обратной зависимости от знаний подчиненных. Учитывая, что на Мисту за птицы залетают, однозначно

(17) Кроме этого, ему не мешало бы знать внутреннюю структуру и ограничения платформы.

(16) И что тебе это знание даст для управления?
Управлять программистами это значит держать их на коротком поводке.

(20) тогда зачем он нужен? - пусть техконсультант всем и рулит :-)

(26) Эффективный менеджер, куле

Нафиг он вообще такой нужен.

(26) а как он их будет держать? ему скажут - эта работа на 8 часов, а на деле - за полчаса можно сбацать

(27) Раздавать всем звиздюлей. А то шибко умные попадаются. Вместо работы по проекту начинают изобретать Сверх Гениальные Программы.

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

должен ли руководитель атомной электростанции знать как она работает и как организованно у нее все внутри и снаружи?

Любой руководитель должен досконально знать работу своих подчиненных. Исключением являются только непосредственно бизнесмены.

(31) все подряд - звиздюлей? или избирательно?
если второе - то как он отличит зерна от плевел?

Тимлидер не должен уметь программировать?
А мальчики/девочки для подписания бумажек теперь все рукоблудители проектов?

РП бывший пилот.
Управлял БОИНГОМ, вот руководство думает БОИНГОМ же сложнее управлять, чем УПП, значит справится!
Самое интересное буду выкладывать в этой ветке, пока не закроют её!

(30) Отличить работает человек или в конру режется можно и без знания 1С. Халтурщики которые левые проекты делают, на себя работают тоже на раз вычисляются без знаний чем процедура от цикла отличается.

Учитывая специфику 1С.

(37) не надо грязи! руководство думает, что твой РП просто хороший парень, с которым приятно пить пиво и пилить бюджеты.

(37) Если бы он раньше руководил овощной базой, т.е. людьми, а не железякой тогда было бы больше пользы для проекта.

Хотя вроде практически все руководители в разработке успешных игр - бывшие программисты.

(41) выясним скоро!

+41 хотя не исключено, что у него есть так же талант руководства людьми и при назначении на должность РП это учитывалось

(42) То игр, а то 1С!

(21) кхм...
руководить разработкой 1С можно не зная 1С...
руководить группой программистов не имея представлений о программировании неполучится, руководитель автоматически переводится в разряд постановщика задачи - прокладкой между конечным пользователем и программистом... "переводчик с кошачего"

Должен быть как минимум бывшим программистом, но не обязательно практикующим.

Иначе такая фигня может получиться :)

Но в теории знать про все возможности. т.е. достаточно курсов 1с

(8) пардон так руководитель разработки или руководитель проекта

(46) вот, именно - постановщик
а то по Ахиллесовой схеме проги сами себе задачу ставят и сами выполняют, а РП их только попинывает для профилактики (отвлекая от работы)

(0) не царское дело в п.де копаться

Он должен быть скорее квалифицированным пользователем и относительно неплохо разбираться в структуре данных

Должен, ибо руководить процессом можно только понимая в нем, иначе, ИМХО результата не достичь. Есть правда одно "но": Если для такого руководителя в случае провала проекта всегда проканывает: "Это починенные м..аки, а я весь белый и пушистый". Тогда, правда, вообще чем хочешь можно руководить :)))

(49) В (8) Это уже нанятый РП, в (0) Это поиск РГ, пытаюсь доказать руководству, что этот человек должен знать 1С!

(0) Руководитель никому ничего не должен из своих подчиненных, это ему должны выдать результат уже готовый, за который платять бабло, а как и что крутиться - это не его дело.

(5) Видимо АвтоВаз По этой же причине до сих пор в зачаточном состоянии) РУководителей полно) но непонятно чем они руководят)

Я сейчас работаю с мужиком, который очень хорош в качестве постановщика задач - когда то давно он сам настраивал 1С 6.0, когда появилась семерка он для себя решил, что сложность программирования в семерке уже переросла его возможности программирования и разбираться с семеркой как программист уже не стал, то же относится и к восьмерке. Однако в качестве постановщика задач и придумывания новых возможностей для пользователя оно очень хорош...

(38) в экран его монитора смотреть целый день будешь? о_О

Была одна бабушка, так всё время себя стукала в грудь, якобы ещё на эвм "наири" программировала решение уравнений. И поэтому программа должна работать вот так!
И конечно же все работало не так. Результат - пшик.

Руководитель должен быть компетентным, прежде всего. Любой мало мальский современный молодой чел, даже от 40 лет, в вузе программил хотя бы лабораторные работы.

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

(57) Да, только у 1С всё таки органиченные возможности, и хотелки постановщика задач не всегда реализуемы(или реализуемы с большими трудозатратами)

(55) а когда заказчик и начнет что либо требовать через суд, то отвечать будет как раз руководитель, т.к. тупому руководителю можно наврать все что хочешь

(0) Если он не умеет кодить, то зачем он нужен? Руководить все с армии умеют )

(57) у меня финдир на молочном делае такой. Настраивал 6ку сам. потом я появился и 7ку все делал я. но он был в курсе возможностей 7ки и ставил задачи очено грамотно. Сам даже в екселе макросы пишет когда надо.

Так что достаточно чтобы человек был не дурак, и знал возможности инструмента. А быть конкретно спецом в 1с это не обязательно. Все должности выше ведущего прога, практическое знание 1с вообще не требует. более важно даже умение понимать бизнеспроцесс и описать его для ТЗ

(60) Хотелки квалифицированного постановщика задач реализуемы всегда, хотя бы потому, что квалифицированный постановщик задач пусть даже на уровне квалифицированного пользователя, но знает возможности движка.

Жесть, вначале тему прочитал как "Должен ли руководитель группы разработки 1С умереть..."

Должен хотя бы на минимальном уровне, чтобы понимать чем занимается то.

(63) А мне вот интересно, в чем разница, между руководителем группы разработчиков (тимлидером по буржуйски) и ведущим прогом?

глупый вопрос

скорее не должен. но структуру конфигурации должен представлять хорошо.

с другой стороны грамотное ТЗ для кодеров составить без знаний про разработке будет тяжело.

Подводя итоги темы:

Всем кому я должен, я все прощаю ;-)

должен ли разработчик 1с знать бухгалтерию? - нет
Но как ты будешь внедрять и программировать для бухгалтерии если ты ее не знаешь?

Руководитель который не понимает в программирование как отдает задания?
ты напиши вот эту шняга, а ты вот эту?
Указания раздавать любой дурак может и наказывать за сроки тоже.

У хорошего руководителя в голове должен быть такой чертеж, что там все ходы прорисованы

А если все программеры пошлют его нафиг и уволятся, кто тогда расхлебывать будет?

Руководитель не бригадир, он должен прежде всего обладать знаниями в области менеджмента. Когда людьми руководит хороший программист/токарь/строитель - получается не деятельность, а не пойми что.

Не руководитель должен решать, регистр сведений или справочник использовать, а программист. Руководитель должен уметь поставить задачу и принять результат.

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

(73) +1. Более грамотно, чем я. Мой респект.

умный и знающий руководитель не берется за невыполнимые и труднорешаемые задачи,
а неумный и незнающий руководитель берется - и часто достигает результата :)
(0) твои боссы сделали правильный выбор:)

(66) ведущий прог- должность техническая. Ведущий прог он исполнитель, хоть и ведущий в комманде прогов. РП - это административная фигня.

(73) а прогам не пофигу? это гемор того, кто дает задачу такую. да и вообще вы сильно преувеличили. в 1С можно сделать все что угодно, это некоторые проги утверждают обратное.

(74) я все не стал читать, сорри, если сильно сплагиатил)

(77) энтузиаст?..
"1С можно сделать все что угодно" - не провоцируй толпу на ненужный холивар..

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

(73) опять же вы в крайности впадаете. кодить уметь в 1с и знать 1с и ее возможности, вещи разные, Знание ТТХ танка например и реководство боем отделения танков совсем не подразумевает умение управлять танком.

(79) реалист.

(80) почему-то все начинают рассматривать какие-то крайности в чем-то от чего принимаются неправильные решения и дело не движется.

(77) Лично мне не пофигу. Если такой вот м..дак будет ставить мне невыполнимые задачи, а потом еще применять схемы мотивации по результатам выполнения, то он очень быстро отправится в далекое эротическое путешествие вместе с той компанией, где он работает.

(76) Тааак, а в чем тогда разница между тимлидом и РП?

(77) "это гемор того, кто дает задачу такую". Нет, это гемор того, кто ее выполняет. Я свидетель.

(0) должен. Другой вопрос насколько хорошо... Это зависит совмещает ли он собой функции ведущего прога или нет.

(0)Ответ не так однозначен.
Кодировкой на скорости владеть не должен, но, должен знать все этапы разработки.

(85)

A team leader or team lead is someone (or in certain cases there may be multiple team leaders) who provides guidance, instruction, direction, leadership to a group of other individuals (the team) for the purpose of achieving a key result or group of aligned results. The team lead reports to a project manager (overseeing several teams). The team leader monitors the quantitative and qualitative result that is to be achieved. The leader works with the team membership

(83) Я не имею ввиду то, что РукИТ должен быть профессиональным программистом такого уровня, что сможет заткнуть любого подчиненного. Он должен быть знаком с решением, которое находится на поддержке, знать предметную область, и, несомненно, уметь руководить.

Он не должен быть кодером, и, уж тем более, не должен этого делать.

(77) Если задача не формализована, а то, хуже, неформализуема в принципе, или имеет в формулировке внутреннее противоречие, то её нельзя сделать ни на 1С, ни на каком-либо ином языке программирования.

Если группа 50 чел, то нафиг,- ему бы успеть работу поделить, сукачей выслушать, обаять нужных, обос#ать ненужных, полизать начальству и уйти домой вовремя ;)

(0) Однозначно должен. Может не на сверхъестественном уровне но выстраивать генеральную линию развития проекта нельзя.

З.Ы. Те кто пишет "Не должен" с логикой "Руководитель должен только руководить" - почитайте про менеджмент в компаниях IBM и Pepsi. - там у руля стояли то кондитеры то вообще фиг знает кто - результат - временные выпадения с лидерства в рынке.

(83) это не крайности, а закономерности.

(93) в Билайне стоял шоколадник и теперь Билайн самый аутсайдерный опсос

(93) попробуй ответить на вопрос: умеет ли программировать руководитель направления экономических программ фирмы 1С Харитонов?

(95) Не взлетит. Приведи пример из области ИТ.

Самое плохое если чуть чуть сталкивался с прогр. причем давно

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

Он не обязан быть хорошим кодировщиком , но знать принципы построения запросов , понятия о оструктурах данных и т.п обязан.
Руководитель группы разработки в первую очередь архитектор и пректировщик системы , а не зная принципов платформы (пусть не детально но достаточно глубоко) , можно такого напроектировать...

(93) и чепуху про IBM гнать не надо.

Должен уметь грамотно ставить задачу, разбираться в алгоритмавх

(97) я привел пример в (96)

(0)Я бы сказал "Обязан!"

(100) для этого надо уметь программировать? зачем РП должен вникать в то, как оптимально постоить запрос?? Он что еще за прогами должен проверять что-ли все??

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

(85) РП еще бюджет и оплату курирует, по моему.

(105) речь не про РП, а про руководителя группы разработки. То есть это человек, который координирует работу 3-15 программистов, ставит им задачи, отвечает за правильную архитектуру разработки, решает сложные вопросы разработки и т.д. Как он может не знать программирование, что за бред. Он должен быть опытней любого из программистов в своей группе.

ИМХО так как некоторые вещи должен сам допиливать  мало ли - прогер уволится или умрет не дай бог, да и мало ли какие форс мажоры

(107) глупости. Сколько строчек кода знает Билл Гейтс из десятков миллионов строчек кода Windows?

однозначно. Это всё равно, что руководить стройкой, но не знать как строится дом

(109) думаю даже билл гейст знает концепцию уствойства своей виндоуз и очень даже хорошо. А не надо путать топ-менеджеров, менеджеров, РП, ген директоров компаний с мелкими руководителямя пятком программистов..

(0) Нет. Я знаю конкретные примеры, где руководитель в коде совсем нуль, но прибыль из его проектов извлекается ого-го.

(109) Билл Гейтс -- руководитель группы программистов из 3-15 человек? 0_о

(105) Он так может запректировать архитектуру , что блин запрос к ней фиг построишь :) , или сделает её наооборот слишком избыточной , и следовательно оптимальной . Что бы спректировать архитектуру оптимально необходимо знать особенности платформы . Другой вопрос конкретная реализация задачи , особенности конкретного кода , непосредственный алгоритм - в этом вопросе программист-исполнитель (программист) может превосходить руководителя группы разработки.
Руководитель видит задачу шире
Исполнитель копает её глубже

Руководитель группы разработки, должен.
Иначе приедтся вводить еще должность Ведущего программиста.

кто нибудь себе представляет схему работы

Руководитель проэкта - Руководитель группы разработки - ведущий программист - програмист.

тем более в 1С одинесниг обычно триедин.


3 начальника на 1го-3х прогеров XD
даже 4ре еще Зам. диреткора по ИТ.

(105) Ты опять про РП. А в сабже речь вообще-то не про РП идет.

Руководитель группы разработки <> руководитель проекта
Руководитель группы разработки = ведущий программист (все таки программист)

у меня были такие руководители, работа выполнялась на ура.

(111) а что, принципы менеджмента в случае с организацией, производственным участком и пятком программистов различаются в корне? Вот уж не думал...

Должен ли руководитель группы разработки 1С уметь читать или умножать числа?

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

(121) +1
ваще жесть с таким РП работать

(117) с чего это вдруг ведущий программист стал руководителем? Он ни коим боком к категории руководителей не относится.

(115) http://www.wyllf.ru/prikol/64091-zhila-byla-odna-komanda-grebcov-13-foto.html

(123) а ты думаешь руководитель, это тот кто сидит в кожаном кресле в своем кабинете и ничего не делает? Руководитель группы программистов-это как сержант. Просто самый опытный ответственный и задротный программист, которого поставили над остальными чтобы было с кого спросить..и не более.

Руководитель проекта может быть одновременно рукуводителем группы разрабочиков
Если руководитель проекта не разбирается в программировании , из числа прогов назначается (либо сам сабой не формально образовывается) ведущий программист (лидер команды) , и управление пойдет двухступенчатое . В больших проектах и особенно при наличии нескольких команд в одном пректе это нормальная ситуация , но для команды не более 5-7 это излишество.

так что не путай сержантов с полковниками)

(117),(123) а кто должен клеить результаты работы 3х программистов над одним объектом, допустим?
Руководитель группы или ведущий программист?

(126) У ТС уже есть РП, который не разбирается не то, что в программировании, но даже в функционале внедряемого продукта ;-)

(128) ведущий программист. Но еще раз повторяю, ВЕДУЩИЙ ПРОГРАММИСТ НЕ РУКОВОДИТЕЛЬ.

(114) Для этого есть обсуждение предварительное с прогами о том что они могут сделать.

Кстати, вопрос к ТС. А сколько вообще разработчиков то в группе планируется?

(123) Когда работают двое , один из них по любому старший

(133) старший <> руководитель

(128) а это как команда организована , сколько в ней человек и какова конкретная задача . В данном случае ведущий программист , но некоторые задачи руководитель группы .
Старший (или ведущий) по любому руководитель в рамках должностных иснструкций , руководство между прочим может быть не только административным но и ФУНКЦИОНАЛЬНЫМ , надо четко их различать

(130) еще помучаю вопросиками, Кто устанавливает нормы в часах?, Вырабатывает единый (корпоративный) стиль программирования и т.п.

и я правилльно понимаю, что если есть Руководитель проэкта и Ведущий программист, то Руководителю группы разработки просто не остается должностных обязанностей?

Я вообще к чему спрашиваю, эфективно ли иметь связку
Руководитель проэкта - Руководитель группы разработки - ведущий программист. И при каком примерно количестве народу.

(128) таким образом ведущий программист осуществляет функциональное руководство в рамках решения задачи , административным его нефиг нагружать , у него другие задачи, Руководить группы разработчиков осуществляет и административное и функциональное руководство , РП в первую очередь администратор и кординатор причем не между самими программистами , а например между группой разрабочиков и заказчиками

Вообщем хоть кто-то из руководства должен разбираться в 1С, иначе отдел превращается в черную дыру ).

Руководители группы разработки балласт, бесполезные людишки. От их знаний ничего не зависит.

(135) руководители - это отдельная категория персонала, также как и специалисты, рабочие, служащие.

"Косынка программа и Windows программа, ведь они же обои работают на компьютере" Так что ли?

а ТС совет, берите не знающего. Можно будет ему выдавать работу завышенную по времени в 2-3 раза. и еще намекнуть на не умелое руководство в случае ошибок.

Хотя жизненый опыт мне подсказывает, что раз на должность РП взяли летчика (читай друга/знакомого руководства оргнизации), то и на должность РГР возьмут друга/знакомого.

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

(136) Для крупного проекта вполне эффективно , по другому серьезный прект и не сделаешь . На практике (в группе 3-7 чел) и если над проектом работает одна группа как правило совмещаются должности
Руководитель группы разработки = ведущий программист (малие группы 3-4 чел)
либо
Руководитель проэкта = Руководитель группы разработки (чуть большие группы 4-7 чел)
Из практического опыта не эффективно загружать ведущего прога административным управлением или планированием , он должет решать чисто технические (програмные) вопросы

(140) Тем не менее нижнее звено руководителей должно непосредственно разбираться в работе подчиненных, кто-то же должен принимать работу не в виде "черного ящика".

И да, нет никакого "административного" руководителя. Есть линейные (руководители цехов/подразделений) и функциональные (финансовый директор, директор по персоналу).

(123) синеор (ведущий) назначает стаффам к выполнению часть своей работы.
ну так это везде, кроме твоего места работы, видимо.

(143) а главный инженер лезет в двигатель, чтобы посмотреть как отремонтировали?

(146) Ты опять полковников с сержантами путаешь. Главный -- нет, а начальник цеха может и полезть.

(144) Когда это финансовый директор осуществлял функциональное руководство ИТО ? Отчасти административное (в области например фондов и т.п.) но НИКОГДА функциональное , он просто не компетентен в этих вопросах

(145) ведущий программист = специалист.

(149) ХА ХА!

а просто программист = стажер?

(146) А мастер участка так точно полезет :)

Время офисных креветок.
Чуть пролез по головам остальных - "руководитель" и знать ничего при этом не надо.

(151) Видимо, по мнению Пузакова, мастер участка уже не руководитель.

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

Должен ли главный бухгалтер знать план счетов?

(148) может еще директора по персоналу отправим на склад, партию картошки принимать?

1. Умный человек никогда с кодами сидеть не будет.
2. Когда татаро-монголы шли на Русь, то хан всегда стоял во время боя на возвышенности вместе с женами и детьми, в отличии от русских князей.

(156) нет, принимать партию картошки отправим директора по закупкам, если без него его подчиненные не смогут справиться.

(157) ну и где теперь эта монголия?

(157) Тумены, сотники и десятники тоже на возвышенности стояли, вместе с ханом?

(148) директор по персоналу, финансовый директор, директор по маркетингу - ФУНКЦИОНАЛЬНЫЕ РУКОВОДИТЕЛИ. И не надо спорить.

(150) нет, простой программист тоже специалист.

(153) мастер - руководитель, а ведущий программист нет. У мастера есть люди в подчинении, а у ведущего программиста - нет.

(157) думаю если хан на рабочем месте озвучит эту позицию, в присутствии своего начальства, то он станет безработным ханом.

(159) В нас внутри. :)

(163) у вас - это у кого?

(161) >> мастер - руководитель, а ведущий программист нет.

Ок. Ты видел хоть одного хорошего мастера, который бы не разбирался в работе своего участка? Я -- нет.

(161) А главный бухгалтер -- руководитель?

(165) не видел. И что?

(166) да.

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

(169) а простите где тут программирование?

(168) Таки главный бухгалтер должен разбираться в бухучете?

(170) Какой пункт из первых 3-х можно выполнить не зная программирования?

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

(172) любой. Достаточно знать платформу и ее возможности. Программистом быть не обязательно. тем более 1С

(171) разбиратся должен. работать бухгалтером на всех участвках нет.

Чтобы стать главой спецназа надо пройти через спецназ, а не по назначению от папы/мамы/ тети/ дяди и т.п.

(171) ты опять смешиваешь разбиратся в чем-то и работать там.

Если я знаю технологию пр-ва молока на уровне технолога я тем не менее не работал технологом.

(171) бухгалтер не просто должен, он обязан. Как-никак он отвечает за учет.

В команде разработчиков, каждый из разработчиков может быть гуру по своей части, а в бухгалтерии гуру учета - главный бухгалтер и лучше его никого нет (подразумевается). Бухгалтерия и группа разработчиков - разные вещи.

(174)
1. Как можно оценить срок решения задачи, не представляя способов её решения?
2. Как можно распределить задачи по сотрудникам исходя из их сильных сторон не представляя как вообще решаются эти задачи.
3. Как можно выявить пробелы знаний сотрудника, не имея возможности оценить его работу "изнутри"?

(174) типичная фраза тупого менеджера, типа я знаю платформу и ее возможности, но не на один конкретный вопрос ответить не может, или отвечает- "я это знать не должен, я знаю платформу и ее возможности", а все остальные вопросы к программистам)

(177) Вопрос в сабже внимательно прочитал? "Должен ли руководитель группы разработки УМЕТЬ программировать", а не "Должен ли руководитель группы разработки программировать "

(178) а значит руководитель программистов не отвечает за разработку?..вот ты и попался)

Не обязательно, ему важнее знать предметную часть, извне возможности платформы и самое главное - руководить кодлой кодеров.

Должен быть в теме.

(178) Чем принципиально отличается группа разработчиков от бухгалтерии или производственного участка?

не должен

(179) Ты никогда не будешь руководить чем-то. в тебе комплекс того, что ты не решишся что-то сделать потому, что ты этого не знаешь.

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

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

(185) Тьфу, проголосовал случайно.

"Насяльника, садись. Пагаварим па брацки.
Ты обои клеить умеишь?"

(180) типичный ответ того, кто аргументировать и не может, приводя примеры из разряды перебранки баб на базаре.

(170) Объясните мне:
Программист А знает что такое "Рекурсия"
Программист Б не знает что такое "Рекурсия"
Теперь берем, Руководитель А знает что "Рекурсия" это основа.
Руководитель Б вообще понятия не имеет что это такое и с чем её едят. И какой руководитель определит стадо баранов у него или не баранов? "Рекурсия" для примера взята, можете подставить сюда чтонть другое, основы запросов, да просто отличие процедуры или функции, короче все что угодно.
По мне дак руководитель А более компетентен, чем руководитель Б

(187) То есть, по твоему, руководить непосредственно разработкой вообще не нужно? Пусть каждый пишет как хочет и что хочет, так?

(187) если руководитель во все не вникает, то он зависим от своих подчиненных. Отсюла вывод- подчиненные будут им вертеть как хотят, второе- другие руководители, клиенты не будут его ни во что ставить, а будут общаться с его подчиненными, так как это более продуктивно.

(187)+если руководитель на любой вопрос клиента или своего начальнника будет звонить или бегать узнавать у своих подчиненых, то долго он не продержится

(191) Глупо увеличивать "умность" своих работников. Это косвенно является увеличением трудоемкости, а значит влечет снижение качества управления.
Есть другие способы определить кого пора уволить.

(187) Вникнуть во все сам, и сделать все сам -- это две большие разницы.

(187) никогда не говори никогда, дружок.. А то жизнь такая штука, знаешь..

(193) Компания работает за деньги. Размер определяет руководитель. После оплаты - доступ к телу (персоналу) исполнителя. Кроме денег вообще мало чем нужно интересоваться настоящему начальнику.

(195) объясните поподробнее ни чего не понятно.
Глупо увеличивать умность, от этого увеличивается трудоемкость?

Ладно, тогда по-другому. Представим, есть следующая команда:
Вася, 7 лет программирования на С++;
Коля, 6 лет программирования на С++;
Дима, 8 лет программирования на С++;
Петя, читал книги по С++, за спиной 4 года руководства людьми, оканчивал курсы МВА.

Вопросы:
1) кто из них будет руководителем?
2) если руководителем будет не опытный программист, есть ли у команды шансы выполнить работу?

(192) Для проверки кто и ка что сделал и оптимлаьно ли достаточно тестов. как хочет не получится по тому, что есть стандарт. Что хочет тоже нет потому, что есть ТЗ.
(193) фигня

(198) ну ты отморозил. Типа дело любого начальника только деньги считать?..откуда только такой бред рождается в головах у людей.. хотя что ожидать от тупых одинесников.

Руководитель должен решать орг. вопросы, поэтому не должен. Каждый должен заниматься своим делом. Если бы я умела это делать - была бы руководителем:)

Ибо, если программеру руки оторвёт на войне с бухами, то руководитель всатанет за пулемёт и продолжит благое дело!


ПыСы.
Вот у нас отдел сократили, и прога прогнали (по сокращению..)
И я, как бывший начальник теперь и прог еще...
Контора такая кстати:
Юрлицо+ 7 филиалов. + еще 8 юрлиц в стадии присоединения к головной. По 8-городам.
Спиртосодержащее со всеми вытекающими...
Юзеров в базе (УПП) около 50-челов + торговые с КПК, штук 70 по стране.
+ Юзера в разных других базах, торговли, ЗиКи, ЗУПы, БП, Бух77,
И нас двое в окопе, я и сисадмин мой...
Что скажете, это нормально?

+ (204) кстати, проголосовать забил..

(199) Если вы занимаетесь более наукоемким или более сложным делом, то его всегда можно выполнить силами персонала поглупее, но с большими трудозатратами. Это ведет (ВСЕГДА) к падению темпов экономических процессов на предприятии. Поэтому джумшуты, клеят обои, остаются дураками и живут более стабильно, чем постоянно растущие офисные работники, рост которых не всегда нужен компании.
Чем проще построен бизнес тем он привлекательнее, поскольку хорошо управляем. Только конченые специалисты мыслят иначе, считая что продается не упаковка, а товар.
Руководитель всегда мыслит в другой плоскости.
Ты либо спец-работник, либо обеспечиваешь рабочие места другим людям. Поверьте, не обязательно понимать чем они занимаются. Общение с любимыми подчиненными - это не самое главное событие в жизни Руководителя. Чего нельзя сказать о подчиненных. Для них Руководитель - это зачастую единственный доступный значимый ресурс.

Вопрос ко всем: вот Вы опытный специалист, на каком-то там механизме собаку съели, в очередной раз работаете с этим механизмом, к Вам подходит руководитель, который "умеет программировать" (за спиной год 1Синья), и начинает давать советы и "координировать". Какова будет Ваша реакция? И на сколько полезны будут знания руководителя?

(206) Согласна, что рост специалиста не всегда нужен компании - 100%. По поводу того, что для руководителя общение с подчиненными - не главное - конечно, они ведь не платят ему зарплату:)

(207) руководитель не будет так делать - нормальный:)

Выскажусь. что мне кажется нужно обязательно знать РП
1. классику - управление проектами - РМ Боок настольная книга
2. хорошую методологическую подготовку  самостоятельного обучения
3. навыки управления людьми (желательно MBI )
а далее по желанию, смотря от уровня необходимости погружения в проблему.
Если задача задана - сделать проект и нет особых ограничений по ресурсам , тогда  один хороший технический заместитель и аналитик вот собственно и все что нужно.
а если есть ограничения - тогда время на погружение в специфику области.
Был у меня один РП - одной из любимых его фраз была "Не царское это дело"....очень качественно делал проекты, команда была ориентирована на результат.

(200) В этой команде Петя не нужен.
А руководителем следует назначить любого из 3-х, кто лучше умеет руководить людьми. Даже если у него нет диплома МБА.

(201) >> как хочет не получится по тому, что есть стандарт.
И кто должен следить за соблюдением стандарта? И кто его должен сформировать, или выбрать?

(201) На один огромный металургический завод пришли иностранные хозяева, купили. Заметили что завод потребляет огромное количество воды, без неё производство не работает.
В первый месяц сделали фактический замер. Во втором ввели лимиты по воде 50% от факта.
Цеха на это посмотрели с недоумением ибо о потреблении воды раньше вообще никто не думал. Хмыкнули удивленно и пошли дальше работать. В следующем месяце лимит был урезан ещё на 30 %. Цеха начали роптать ибо реально воды не хватает, а работать надо.
Повысили на 15 процентов лимит и сделали из него норматив. Однократными недоразумениями в связи с нехваткой воды и единовременными потерями сумели сократить затраты по воде более чем в два раза даже не вникая в суть происходящего.
П.С.: Руководитель не должен даже пытаться заменить собой работника. Но может заменить работника другим работником в любой момент если руководитель настоящий.

(208) Руководитель не должен даже пытаться заменить собой работника. Но может заменить работника другим работником в любой момент если руководитель настоящий.

(200) Руководить будет Арман Есбекович.

(210) Снова чукча не читатель ... Речь не про РП идет.

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

(211) Применение подробных расчетно-аналитических нормативов в планировании вовсе не обязательно если это не повышает существенно экономическую часть ибо, опять же, дико трудозатратно. Применений отчетно-статистических показателей выбирают гораздо чаще. Здесь вопрос о "выбирать" не совсем уместен...

(200)
Петю Руководителем проекта
Диму на курсы управления людми и руководителем группы разработчиков
Колю или Васю ведущим прогом

Вообще прежде чем дойти до стандартизации люди много-много бюджетируют...

(218) Не правильную они голосовалку сделали. Надо по именам было.

Все кто тут отписался с "не должен", видимо не разу не работали под таким чутким и бдительным руководителем. А если бы хотя бы раз ощутили всю прелесть - тогда варианта было бы два:
1. должен
2. валить на ух от такого м#ка.

(209) ну так если специалисты все сделают сами (а они сделают, в своей области они утрут нос руководителю на раз-два), то зачем нужны "дилетантские" умения руководителя?

И насчет "оценки сложности", "оценки трудозатрат" и прочих вещей, для которых  якобы нужно знание 1С, - у каждого из специалистов есть языки, по 1 штуке на рыло. Для оценки трудозатрат, в нормальной деятельности, имеются:
- нормы и регламенты;
- согласование с исполнителями.

(221) +1

(222) Почему дилетантские? Почему бухгалтерией дилетант в БУ управлять не может, а группой программистов может?

(216) Вы забываете что есть отрасль образующие предприятия, а есть работающие на высококонкурентных рынках. Я вот в миссии одной строительной компашки недавно видел: "Извлечение чистой прибыли". Очень хорошо написано.
А рынок айти на сто лет не спланируешь, очень бурный. Читайте внимательнее, я же писал про ТЕМПЫ. Если вы беретесь за любое дело, которое вы не в состоянии завершить, то получается недостроеный СССР с очень сложной красивой, возможно даже достижимой целью. Но не в этой жизни.
А продавать коробки 1С может и дурак, как показывает практика. Легко и быстро. Вероятность того, что у вас условия уникальны и значительно лучше среднерыночных крайне мала.
Ненужная компетенция сотрудников и накапливающаяся в них НЕРЕАЛИЗОВАННОСТЬ - это ложный повод уволиться из компании ибо "Я ТАКОЙ!", а мое Я тут не ценят...

(222) Одними регламентами и нормами сыт не будешь , нужно конкретное погимание проблеми знание как эти проблемы решить.
Если бы все решалось нормами и регламентами , руководители были бы не нужны , их бы калькуляторы заменили.
Кроме того руководство это в значительной степении ответсвенность за принятие РЕШЕНИЯ.
Как говорится генерал приля решения захватить населенный пункт , штаб разрабатывает варианты решения данной тактической задачи , командиры полков там или бвтальонов на местах воплощают этот замысел , а если стратегически решение о захвате этого пункта оказалось ошибочным - генералу и отвечать

(224) потому, что в бухгалтерии все крутится под главбухом, а в группе программистов каждый сам решает, как лучше сделать. Чуть ли не механическая, и чуть ли не полностью творческая работа - разные вещи.

(216) Здесь уже обсуждали на днях выгодно ли выращивать спеца или дешевле брать готового. Всегда нужно брать компентентного и готового, при чем компетенция должна точно совпадать. Спецы широкой компетенции - плохие работники.

(226) А если, при этом, сержанты и лейтенанты не будут знать за какой конец ружье берется, то хрен они что захватят, каким бы стратегически верным решение ни было.

(224) Угу угу , представляю результаты работы если каждый рядовой прог в команде САМ решает как лучше сделать , может он еще и сроки определяет да и вообще всех посылает .

(227) >> а в группе программистов каждый сам решает, как лучше сделать.

Когда происходит так, из этого, как правило, ничего хорошего не выходит.

(230) вот представь, у меня за спиной полтора года программирования, а у подчиненного 10, как я оценю время выполнения работы подчиненным? По своему времени - так он быстрее меня сделает, линейной зависимости между опытом и скоростью работы тоже никакой нет. Как оценивать?

(229) Естественно , но вообщето за боевую подготовку и качество обучения солдат и младших офицеров отвечает командир полка или комбриг , выше уже стратегические задачи , ниже чистая тактика и исполнение приказов .

(228) Спец со временем как правило расширят уровень компетенции и переходить на руководящие должности

(231) например? Когда редактируете процедуру проведения документа, за спиной стоят пять советников? Или каждый новый реквизит добавляется только после общего голосования?

(232) если у тебя полтора года работы прогом и за плечами нет нескольких лет ОПЫТА на руководящей должности (пусть другого профиля) , нужно спрашивать с того идиота который тебя поставил руководить группой разработчиков

(232) По времени выполнения им других, однотипных задач, например.
Но как ты поймешь, что задачи однотипные, если вообще не имеешь опыта программирования?

(235) глупости. Как будто начальник производственного цеха должен поработать токарем, фрезеровщиком, стропольщиком, сварщиком и уборщицей.

(236) я обращусь к нормам и регламентам, и спрошу у исполнителя ;)

(231) Модули проведения даже разных документов (работающих с со сходными данными) должны отвечать неким стандартам , использовать глобальные процедуры , и принципиально схожие алгоритмы , кодирование идет в рамках стандарта
Да блин хотя бы принципы наименования объектов метаданных , или переменных должны быть стандартизированны
А то один пишет ДатаКонца , другой ДатаОкончания , третий КонечнаяДата , разбирайся потом

Скорее да, чем нет.

это факт

(239) а без руководителя, разбирающегося в программировании, шансов на согласованную групповую разработку нет? :)

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

Очевидно

(237) Ты тролль , утверждаешь одно а потом сразу же противоположное
Ты на производстве работал вообще или офисный планктон ?
Любой инжинер это минимум пятый рабочий разряд , не возможно стать начальником цеха не имея инжинерного образования (ну если только ты не племянник генерального)
И в отличиие от рабочего который 20 лет у станка простаял и может такую деталь отфрезеровать что тебе и не снилось , у него нет ОПЫТА руководящей работы , прежде стать начальником цеха , ты должает поработать мастером - начальником участка - замом по производству , ну или проити какую нибудь похожую цепочку руководсва . Нормальный мастер участка может заменить практически любого рабочего при необходимости

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

(246) Хорошо, но может не быть

(245) это ты себе противоречишь. Как мастер, не прошедший специального обучения, может заменить токаря, фрезеровщика, стропольщика? За время обучения в институте он ни разу за станком не стоял, и ничего не строполил. А уж извини, с умением вытачивать детали не рождаются, и после прочтения книг эти умения не приходят...

Если группа программистов занимается разработкой по готовому ТЗ, то не обязан, и выполнять чисто административные функции, если же у вас команда, занимается собственными разработками, то конечно да и быть профи.
Пример из сериалов: др. Хаус, сам провифи, выше на голову всех, а административные функции обычно возлагаются на самого педантичного и исполнительного(то бишь зам по хоз части).

(246) это окончательное решение должно касаться "укрупненных" деталей: добавлять или нет возможность учета НДС, какие проводки будет делать документ... Все должно быть в рамках разумного, не нужно руководителю принимать решение в отношении наименования переменной.

(248) Могу сказать так, по первому образованию, я горный инженер электромеханик, и прежде чем дорасти до механика участка пришлось пройти ступени со слесаря 3-го разряда(на институтской практике) и по этому я мог заменить любого дежурного слесаря, и по автоматике и по машинам, и ленту клепать то же умею

(251) когда поработавши - эт понятно. Но не когда был мастером и вдруг подошел к станку.

(250) Я вообще-то про решения вообще не касающиеся функционала речь вел.

(251) Ну если у вас извините за выражение, рук разработки решает какие испоьзуется объекты, то гнать надо разрабов вшею

(246) тогда это не группа программистов, а группа "кодеров", любой программист в команде должен уметь принимать решения самостоятельно, но в рамках той стратегии, которую наметили ранее. Если же он отступил от стратегии, и ввел новый объект мд, то должен уметь обосновать данное решение.
Я согласен что проверять оптимальность кода, это маразм!!!

(254) И кто примет такое решение?

(254) Маразм менять в стандартных МД что то не поставив в известность остальных участников разработки.

(253) а разве для решений, не касающихся функционала, нужно уметь программировать? :)

Может ли руководить не умея программировать - можно.
Должен ли уметь программировать - без всякого сомнения должен.

(255) >> но в рамках той стратегии, которую наметили ранее

Кто-то должен принять решение какую именно стратегию наметить? Если мнения спецов вдруг разделились.

>> Если же он отступил от стратегии ...  то должен уметь обосновать данное решение

Перед кем обосновать?

Конечно.

(258) Как раз для решений, касающихся функционала, уметь программировать не обязательно. А вот для решений, касающихся реализации -- непременно.

(258) Для принятие решений ты должен знать приметную область от и до(еще раз подчеркиваю, если у вас команда разработчиков
). Так как для принятия окончательного решения, руководитель должен взвесить все за и против, так же продумать все плюсы и минусы того или иного решения, и принять вариант решения.

(262) а программисты не в силах решить как реализовать? Зачем ограничивать их в работе?

давайте вообще определимся в понятиях =)
у многих разные понимания о структуре построения отдела и понимании должностных обязанностей.
Отпишитесь лучше у кого какая система настроена:
1ый уровень Руководитель ИТ
2ой уровень Ведущие специалисты (Ведущий программист, аналитик, старший инженер)
3ий Специалисты.

Кто из ни руководитель, кто не руководитель? =)
Я вижу 1 и 2 уровень это руководители.
1ый уровень, на детали начхать важна общая линия.
2ой уровень, выросли из спецов, на детали не начхать, могут найти любое решение.
3ий уровень исполнители задач поставленных от 1го и 2го уровня

(263) ну хорошо, руководитель знает предмет автоматизации от и до, но не умеет программировать, программисты умеют программировать от и до, но плохо знакомы с предметом автоматизации. Неужели руководитель программистам ничего не объяснит?

Проходил я такое в своей практике, еще когда сам руководителем не был. Этот "Постановщик задач", как он сам себя именовал, об 1С имел весьма смутное представление. Все его "руководящие указания" сводились примерно к одному: Сходи к Пользователю, узнай чего ему надо. Потом второй вопрос, сколько тебе времени надо ? Вот собственно и все. Все планы, прогнозы и т.д. я делал сам. Однако получал этот "ПЗ" в полтора раза больше меня. И нахрена козе баян ?

(260) окончательное принятие того или иного решения за руководителем.
перед собственным руководителем.

Ведь если на то пошло задача любого руководителя, обеспечит конформные условия для подчиненных, и пинать и ругать имеет право только руководитель собственный.
Так же руководитель несет ответственность за все промахи его отдела, и на совещаниях в руководстве, не в коем случае на должен говорить что виноваты его подчинены. Ведь по логике, если виноваты твои подчиненый, значит они не достаточно соответствуют требованиям, значит, ты как руководитель не смог создать команду, значит виноват, ты как непосредственный руководитель отдела.

(161) >> простой программист тоже специалист.

повторюсь, так - только твоего работодателя.

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

(266) тогда в команде должен быть архитектор!!!, вот и всех делов.

(264) А зачем им тогда вообще нужен руководитель?
Вот объясните мне, какие функции будет выполнять руководитель группы разработчиков, не разбирающийся в программировании, при условии, что над ним есть еще РП?

Конечно, ибо не зная не возможно принимать решения.

(271) -> (267)

(270) А архитектор, это будет руководитель, или нет?

(274) Не синонимы.

(267) А в итоге, когда были какие ни будь проблемы, провалы, или еще что то он сдавал подчинены?

(274) Архитектор должен видеть куда движется разработка бд, в части прикладного решения(то есть, не всплывала избыточная наполненность измерениями регистров, не дублировалась информация в 33 местах(когда одна и та же информация расположена в разных местах с небольшими инторпритациями))

(271) положит перед собой техническое задание, рядом посадит программеров, и выслушает их жалобы, мол вот на это нужно больше времени, это вообще лучше иначе делать, а то должен делать не Вася, а Петя, так как он в этом лучше разбирается. Пойдет? :)

Короче, он будет заниматься координацией программистов, но не координируя их движения в конфигураторе (и без него справятся).

(277) Это понятно. А с программистами у него какие взаимоотношения? Кто кем командует?

(248) При НОРМАЛЬНОМ высшем образовании (а не купленоом дипломе или платном со скачанными курсовыми) инженер проходит обучение по профильной рабочей специальности .

Первый диплом защищал в 92 году , на производственной практике несколько месяцев отработал монтажником , электриком и наладчиком , и даже после института мог свободно заменить рабочих профильных специальностей , и хотя пришел на производство сразу мастером , прислушивался к своим подчиненным бригадирам

(278) То есть принять согласованное решение по техническому вопросу программисты могут, а кто что делать будет, и за какое время -- нет?

(279) ну наверно он ими.

(281) могут, но тут у них может получиться перекладывание друг на друга, и вот тут как раз руководитель выручит :)

(283) Перекладывание друг на друга получиться может, а такого, что каждый будет отстаивать свое решение по реализации -- не может?

(278) Он лучше знает, кто как пишет и в какие сроки? и вообще сколько нужно времени на наиписание конкретной задачи? а сами они не в состоянии разделить зоны ответственности и сроки разработки? ))

(283) это похоже на работу ленивых студентов и преподавателя, а не команду опытных кодеров

+(284) Вы уж либо крестик, либо трусики ...

Либо группа программистов способна к самоорганизации без формального руководителя, и тогда оный не нужен, либо не способна, и тогда руководить должен спец. А таскать бумажки от прогов к РП можно и секретаршу нанять. На гораздо меньшую зарплату.

(286) Вот только преподаватель, обычно, разбирается в предмете гораздо лучше студентов :-)

Или вот. Ипусь я с блокировками, уже на трехсотый раз прохожу отладчиком одни о те же модули. Видятся два решения: либо переделать три регистра, либо перелопатить несколько тысяч строчек кода. Чем сможет помочь руководитель? Ведь он не владет нужной информацией, он по этому вопросу вообще не владет информацией, так как этим занимался я. И не важно, какая там у него квалификация, раз информации в его голове нет... А ведь при разработке так на каждом шагу: я делаю и вся логика у меня в голове, а другому придется потратить время, чтобы в моем разобраться.

(284) может, но разрулить такую ситуацию сможет не просто умеющий программировать, а обладающих квалификацией выше, чем у программистов...

(289) Руководитель звена этим и не должен заниматься. Зато вот структура регистров, общих модулей, архитектура взаимодействия клиента и сервера, архитектура общих механизмов - это целиком его компетенция. И решение об изменении структуры объектов должен принимать именно он, т.к. только он ответственен за взаимодействие составляющих системы между собой.

(287) не, организация рабочего процесса идет на лево, а программная реализация задачи идет на право. Для первого желателен руководитель, а для второго он совсем не обязателен.

(289) Он владеет информацией, как то, или иное решение повлияет на другие участки разработки. А вот ты, как рядовой программист можешь этой информацией и не владеть.

(287) Скажем так способность саморганизации группы опбратно пропорциональна сложности задачи , причем зависимость не линейная

(292) Вот это как раз более справедливо для бригады грузчиков, а не для группы программистов.

Знаю такого. Уехал в нижний, на зп 150 тыщ...

(289) Он сможет сместить сроки других задач , переложить эту задачу на кого нибудь кто лучше разбирается в реверс-инжинириге .
А программисткая подготовка поможет ему точно оценить сроки исполнения , понять не вешает ли ему сотрудник лапшу на уши по сложности проблемы , да вконце концов просто помочь советом

(291) опять же, а программисты, без участия руководителя, не могут вносить согласованные изменения?

(294) да нет никакой зависимости от сложности. Есть зависимость от количества программистов.

(295) почему?

(289) Логика в голове это плохо , а документирование , а рабочие журналы ?

(254) Программеры и должны принять, на основе консенсуса.

(289) Нет конечно. Либое изменение архитектуры только с благословения архитектора. Рядовой спец просто не обладает квалификацией позволяющей предсказать все последствия изменения архитектуры. Вот скажи, что будет если в поле составного типа добавить еще один тип. Все типы ссылочные, но все изначальные по составу реквизитов не отличались, а вот новый - имеет радикально другой реквизитный состав.

(297) и как же он поможет советом, оценит сроки и прочее, если он это дело в первый увидит? Повторяюсь, какая бы ниипаться высокая квалификация у него там ни была, все равно для полной оценки ситуации ему понадобится время для вникания. Так может лучше я сам решу, как и что делать, а с ним просто согласую сроки? И не понадобятся его знания в программировании... С неменьшим успехом советом мне смогут помочь и другие программисты.

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

(301) а шо такое "радикально новый реквизитный состав"?

У всех документов есть реквизиты:
Организация
Склад
Подразделение
Ответственный
СуммаДокумента

У нового нет ни одного из них, а сумма документа обозвана "СуммаПоДокументу".

(305) ну... некоторые "универсальные" запросы могут погибнуть.

(306) обоснуй?

(307) если где-то получались данные запросом из этого поля через точку, то запрос может просто нарваться на ту самую "злополучную" таблицу, в которой не будет "начального состава реквизитов".

Больше с ходу в голову ничего не приходит, нужно ситуацию смоделировать, а потом смотреть, что и как.

Нарвется. Больше того, вернет в этой ситуации NULL. С точки зрения возвращаемого результата здесь проблем нет. Но старший программист обязан знать о том, почему такое решение нужно отвергать сразу и чем именно оно губит производительность системы.

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

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

Бригадир Петрович (ведущий программист) - так мужики за работу , Вася толкай... Не получается ?, ну сейчас Коля с Петей ломами подденут а Вася трос заведет , поднажми мужики , так Вира ,Майна ,уфф перекур мужики . То есть руководит непосредственным процессом работ

Начальнику цеха пофигу КАК это будет сделано , он знает что это возможно об остальном пусть у мастера голова болит ,а он свои задачи решил.

Мастер уже решает как будут производится работы можно например просто мусор закидать в кузов машины за пару часов (а она будет стоять под погрузкой) , а можно за то же время закидать в мульду а потом её за пять минут погрузить в кузов краном ,простоя меньше значить надо мульду организовать, тельфер достанет до этого места ? если нет надо и кран заказывать , но все равно быстрее получится . Если мастер не сообразит насчет погрузки ему опытный бригадир подскажет , но организовывать все равно мастеру.

Бригадир непосредственно рулит на месте , техника безопасности там , кто посильнее тому ломы , кто пошустрее тот пусть лучше зацепляет , личным примером вдохновить работяг то же не повредит :)

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

Это как прораб, который не в курсе зачем арматуру в опалубку засовывают.

Нда... НЕ должен  - 39%
Эта страна НИКОГДА не будет жить хорошо.

(313) +100500

(311) жги еще , прикольно получается .....

У меня тут был "постановщик" задач.

- Мне нужен документ!
- Хорошо, какой?
- Чтоб там были остатки.
- Так может отчет?
- НЕт! Документ!
- Какие операции должен делать документ?
- Ну... Все под контролем в общем.

Вот так. )))

(316) Программист просто тупой, увольнять его надо ....

(315) Когда я работал на заводе , ломы в нашем цехе считались спец инструментом :) потому , что были из титана , и выдавались в инструменталке по заборной карточке

(318) судя по задоры, в ИТ лом остался тоже незаменимым инструментом ? :)

(319) против лома нет приема :)
Да нет просто вспомнил молодость , хотя в производстве я проработал не много , опыт работы на младших руководящих должностях в большой иерархической структуре потом пригодился

(298) Чем сложнее и следовательно как правило объемнее задача , тем большее количество программистов должны её решать , следовательно зависимость есть .
А по поводу саморганизации - если коллектив из толковых спецов , как правило возникают несколько вариантов решения задачи , возникают споры . В споре конечно рождается истина но до определенного предела .Так что , как говорится мы посовещались и я решил , а то спорить можно до бесконечности , а потом когда и если что то заработало не так , начинаются взаимные разборки , типа "Я же предлагал по другому , надо было меня слушать" , на коллектив это очень пагубно действует .

(317)
Конкретно ты этому программисту за сигаретами бегать будешь, да еще и пыжится от гордости, темнота.

(321) проблема в том, что не имея должного уровня профессионализма, не соберешь толковых вокруг себя...
(322) я вряд ли, а вот ты иронии не заметил :)

должен. если это нормальный проект то над руководителем группы пазработки 1с должен стоять нормальный менеджер проекта

+(323) Будучи руководителем , ты должен не собирать собрание, а самостоятельно знать как решать поставленные задачи , и распределить просто роли между подчиненными

(325) воо, а я вот кодю сафсем мало. НО знаю где что лежит. И кодер мне нужен который бы не умничал а взял то что я скажу и положил туда куда я скажу.
Вот

(323) Следовательно руководитель группы разработки ОБЯЗАН уметь программировать . Должен или не должен заниматься практическим кодингом в рамках работы команды вопрос другой .
Если он совмещает эту должность с должностью ведущего прога до несомненно да , если не совмещает то зависит от от стиля управления или конкретной задачи (ну например когда какой то участок кода или модуль проще и быстрее написать самому , чем писать ТЗ и давать детальные разъяснения)

(326) :), слушай ну прям сегодня какой-то конценсус у нас стобой во мнениях по всем вопросам :), трезвый что ли еще ???? :)))

(327) не должен позволять себя обе..ать недобросовестному ленивому сотруднику :)

(328) в том и фик шо пьяный, видиш без ошибок пишу

(325) Ум хорошо а два лучше . нельзя быть специалистом во всем , если не прислушиваться к мнению исполнителей и к их предложениям ничего хорошего не получится . А вот РЕШЕНИЕ о порядке исполнения задачи и как она в конечном итоге будет решаться должно приниматься единолично

(329) Ну это само собой

(329) Бинго. Я вот на старости лет пингвинов ставить себе начал, а то был у нас админ орал дурниной шо виндовс авно а пингвины форева, так он даже АСПЛинух не поднял, гнида.

(333) :) жесть
(332) а остальное это уже детали
ЗЫ спать пошел, завтра на рынок рано ехать , хотел шурпы сварить , а баранины свежей после 11 уже можо не найти

(334) ОООО

Стой

А ты от кедва буш. Могу ножку баранью переправить

Как-то так.

Знание предметной области будет достаточно...

Ладно, раз так ни в какую, и сугубо личные домыслы побеждают, подойдем с другой стороны. Практический опыт.

Травмирующее воздействие на сотрудников происходит тогда, когда в общении с сотрудниками:
1) руководитель использует отрицательные суждения.
2) делает критические замечания работников в присутствии других сотрудников.
3) не отмечает успехов сотрудников.
4) наказывает несколько раз за одно и то же.
5) не поставив нашел задачи перед сотрудниками, максимально регламентирует его в деталях по выполнению профессиональных обязанностей. (подчеркиваю!)
6) постоянно использует отрицательное подкрепление: порицает за ошибку, промах, при этом он не замечает успехов, считая их само собой разумеющимися.
7) занимает по отношения к сотрудникам позиция требовательного, авторитарного "родителя", который отчитывает сотрудников, оценивает, регламентирует их в мелочах, как маленьких детей.

Это все прямая дорога к демотивации сотрудников.

А теперь, как замедлить демотивацию.

1) Создавать условия для удовлетворения ведущих профессиональных потребностей сотрудников в соответствии с задачами организации.
2) Учитывать то, что эффективность труда работника возрастет, если в коллективе он будет испытывать чувство защищенности и осозновать свою значимость для организации.
3) Относиться к сотруднику как к личности, обладающим огромным потенциалом возможностей, нужных организации, а не как к неудачнику.
4) Изначально относиться к недостаткам в работе сотрудника как к случайности.
5) Помнить, что не ошибается тот, кто ничего не делает, и пропиться к ошибкам сотрудника как к досадному недоразумению, подобному неприятному явлению природы. Ведь как бы нам ни была неприятна слякость, она неизбежна в межсезонье.

В связи с этим хочу поздравить многих участников обсуждения. Вы со своими предрассудками на раз-два найдете способ убить мотивацию сотрудников...

естественно!

(342) Не понятно только при чем здесь мотивация сотрудников . Тема топика "Должен ли руководитель группы разработки 1С уметь программировать" , никакого отношения к мотивации не имеет , а имеет отношение к профессиональным навыкам отдельного сотрудника .
Это вброс , да ?

Спор решается очень просто.

Пригласите в тендер на автоматизацию компании две команды - в одной, где руководитель умеет программировать, в другой где не умеет (при остальных прочих равных).

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

Недавно, именно за счет квалификации удалось склонить одного клиента в свою сторону, хотя они уже начали работать с другой компанией ;)

(344) нет, это прямое свидетельство того, что если над командой разработчиков поставить того, кто будет "принимать решения, добавить объект метаданных или нет", то получим снижение мотивации и ухудшение результата.

Конечно должен

До сих пор привели доводы в пользу руководителя группы: ну вот, без него будут спорить, еще чего доброго разругаются, не будет согласованности...

(345) руководитель второй группы может просто взять время для обдумывания, во время которого все четко согласовать с другими, и результат будет ни чуть не хуже.

Что такое руководство? В это понятие входит организация работ, планирование, мотивация сотрудников на выполнение задания и собственно контроль за выполнением.

Так что мое мнение должен уметь программировать. Иначе как же  будет осуществлен контроль?

И как руководитель группы может мотивировать если не понимает за что ?
Ну к примеру написал я там отчет со сложнейшим запросом , высокооптимизированный , применил новый (пусть даже для себя) хитрый алгоритм , а потом меня хвалят изящно нарисованную экранную кнопку потому , что руководитель группы не знает чем алгоритм от аргонавта отличается ? Тьфу блин

(351)"как руководитель группы может мотивировать если не понимает за что ? ".
Я в этом с вами не совсем согласна.
Мотивировать не за что нужно, а как))).Любого человека можно мотивировать на работу.
И тут уже важно как руководитель знает своих работников (их психотипы и "рычаги" воздействия на этих самых работников).

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

(349) Обдумывание при переговорах на территории заказчика? Это тогда переговоры на месяц затянуться если каждое предложение нужно обдумывать.

Одинаковых объектов автоматизации не бывает, поэтому руководитель проекта должен четко отвечать на желания клиента, оценивать сроки, РИСКИ и стоимость.

Мое мнение, что руководитель должен:
- Уметь руководить (не забываем)!
- Знать предметную область (или хорошо подготовиться).
- Уметь программировать (в нашем случае).

Только тогда эффект от разработки будет максимальным, а изменения планов минимальными.

(346) Ага , получим повышение мотивации , и снижение качества продукции , типичный высокоэффективный менеджмент .
Решение о создании нового объекта метаданных должен принимать именно руководитель группы , или как минимум ведущий прог (но с аргументами)
Пример :
есть некие хранимые данные , но что бы их получить нужен сложный запрос который работает достаточно медленно , и прог независимо решает создать регистр сведений и писать туда данные для оптимизированной выборки в дальнейшем , содает и пишет туда. Другой прог все таки пользуется уже имеющимися данными хотя получает их медленнее . В какой то момент данные расходятся (скажем какой нибудь "Возврат с консигнаци" пишет данные в один регистр и не пишет в новосозданный) что делать будем ? А данные уже избыточные хранятся да к тому же и не корректные.
Именно руководитель группы оценивает необходимость избыточных данных , и если они действительно необходимы (скажем критичны по скорости исполнения так как данные должны выбираться в модуле проведения)документирует , доводит до всех членов группы , и контролирует корректную работу

(351) а мотивация не на полке лежит, это не материальный предмет. Знания программирования тут совершенно ни к чему. Проверить правильность работы отчета сможет человек без навыков программирования.

(354) нет, как раз при повышении мотивации качество продукции улучшается...

(352) Мотивация разная бывает (включая элементарные премии , и даже иногда в виде исключения крепкое словцо)
В посте 340 речь идет прежде всего о морально-профессиональной мотивации , а она невозможна если руководитель группы не является профессионалом в ТОЙ ЖЕ ОБЛАСТИ что и подчиненные .
Что бы похвалить за качественно сделанную работу нужно сначала понять что она качественная

Криворукого спеца хоть перезамотивируй , толку хрен
Что бы понять что он криворукий нужно понимать вопрос не хуже него . А то прог напишет кривой отчет за неделю который формируется 10 мин и думает что его похвалят , руководитель который в программировании не понимает может и похвалит , а на самом деле отчет пишется за день и и может быть сформирован за 30 сек

(351)"Проверить правильность работы отчета сможет человек без навыков программирования." Это конечно может быть и так.

Ну а если отчет составлен не верно? Предположим.Есть ошибки именно связанные с программированием.
Руководитель умеющий прогить найдет ошибки.

(359) Если отчёт выдаёт правильные данные, то всем абсолютнго по барабану, как он написан...

(357) ну вот опять двадцать пять... Мотивацией будет дарение свободы сотруднику. Чтобы он себя чувствовал действительно профессионалом, а не тупо исполнителем указаний. Если обставить гаврика, который будет постоянно в уши заглядывать, и рассказывать, как нужно делать, то мотивация непременно упадет...

(356) а тестеры на что?

(357)"Мотивация разная бывает" безусловно. С этим я не спорю.

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

(360) А если не правильные?

(364) А если не правильные, то тут рукпро не нужен, это и юзвери увидят

И да психология имеет конечно важное значение , но знание программирования и предметной области для руководителя важнее.
Ошибка -  абсолютно нормальная ситуация в работе прога , иначе не было бы альфа-тестирования , бета-тестирования , предрелизов. Как говорится вопрос не в ошибке а в скорости и качестве её обнаружения и устранения. У меня в отделе есть программист который совершенно неадекватно реагировал на обнаруженные ошибки сделанные им (то ли его избивали на предыдущем месте работы за них то ли еще что :)  ) , при этом хороший спец и трудяга . Увольнять не хотелось но и с ошибками надо что то делать . Подкладывал распечатанные баг-репорты не заметно на стол , типа из воздуха появились (никаких баг-трекеров , или оповещений на собрании) - вроде его не так колбасило . Сейчас получше стало и в ступор при обнаружении ошибки уже не впадает.

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

(365) Как это рукпро не нужен?
Без эффективного руководства дело встанет))).

(368) рукпро нужен для постановки задач, а не для контроля выхлопа. Для этого тестеры есть. Или спецвыделенцы, или пользователи.
В прошлой конторое у нас был спецвыделенец, в текущей я испытваю новости на кошках^W пользователях...

(368) дело встаёт из-за кривых рук

(361) Сотрудник должен быть свободен строго в рамках исполняемых задач и поставленного задания . Обсуждать , предлагать можно на стадии предварительного обсуждения и мозгового штурма , причем инициатива приветствуется . Когда решение принято - исполнение в соответствии со стандартами , иначе начнется хаос , причем в в программном продукте
В коммерческой разработке время хакеров-энтузиастов ушло , серьезный проект с ними не поднимешь

(0)
А как он может дорасти до "руководитель группы разработки 1С"
не умея программировать?

Значит он устроился на работу  по "родственным" или по "интимным" связям.

(363) Эффективность руководителя этого звена (а мы говорим  конкретно о руководителе группы разработчиков ) в первую очередь ДОСТАТОЧНО высокие навыки программирования  . Пусть он хоть трижды психолог , и специалист по менеджменту он должен быть в первую очередь программистом ну или как минимум весьма разбираться в этом вопросе . Это не относится например к РП .

(372) Не факт , может быть был управленцем (и весьма не плохим) но по другому профилю . Бедная группа разработчиков.

(360) В корне ошибочное мнение это раз
Отчет это верхушка айсберга и частный случай это два

(375) Обоснуй

Я могу вам сказать только одно.

Я в своей жизни общалась со многими одинэсниками (и тел. интервью провожу и собеседования).
И вот, что я заметила многие из них циничные, наглые, и даже хамоватые. И эти качества в людях преобладают именно из-за специфики деятельности (приходиться откаты прятать, с главбухами работать и т.д.), Чем  квалифицированнее специалист тем более он сложный по характеру.

Ничего лично. Только факты. Огорчить этой фразой никого не хотела.

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

(376)
Как минимум он может быть написан не оптимально
Он может быть написан не гибко
Он может быть низко масштабируемым или не расширяемым в дальнейшем
Он может не корректно отрабатывать исключительные случаи (99 рас считаться правильно а 1 раз не правильно , предварительная проверка идет именно на уровне кода)
Это по поводу правильности
По поводу верхушки айсберга
Первичное значение имеет структура данных (которую еще необходимо спроектировать)
Потом порядок занесения данных в структуру
А потом уже отчеты по данным определенной структуры

(371) а чтобы все было в соответствии со стандартами, нужен надзиратель?

(377) тоже считаете, что над хорошими специалистами нужен надзиратель?

(379) "надзиратель" и руководитель это разные вещи.

Руководитель несет ответственность за всю группу которая с ним работает перед заказчиками или учредителями. Он самый смелый и ответственный и ему доверяют.)))

(360) Пример
Приглашали как то в контору для консультаций (по совсем другому вопросу) , ну после решения вопросов в бухгалтерии пъем там чаек , один из  бухов говорит "Ну я запустила книгу продаж , пойду пообедаю" , а контора то не большая несколько тысяч документов в месяц , мать моя , у них книга продаж формируется на приличном железе в терминале 40 минут , в бухгалтерии думают что так и надо и довольны до усрачки "Она у нас практически полностью автоматическая !!!" . Попросил разрешения глянуть одним глазком на это чудо , это блин не код а ошибка в ДНК , добавил две строки , стала формироваться 4 минуты , можно было бы еще раза в два ускорить но там уже надо серьезно в код лезть.

(378) ну ладно, написал сотрудник отчет для ЗУПа, затратил на написание 10 часов. Руководителю, чтобы оценить правильность, оптимальность, гибкость к доработке отчета придется потратить часа 3... Нафиг нужен такой контроль? Или вы заранее закладываете ситуацию, что специалисты будут глупые и самостоятельно не смогут сделать оптимально?  Так тут уже проблемы в подборе кандидатов, безобразный писк сотрудников не компенсируется наставлениями грамотного руководителя.

(379) Нужен в первую очередь человек который эти стандарты разрабатывает и утверждает , и это не может быть РП потому как его уровень компетенции лежит в несколько другой области

(380) так что же, сотрудники распи..дяи и на них нельзя положиться? Это красноречивыи признак низкой мотивации.

(378) на уровне поиска сотрудников не возможно выявить полноценно его квалификацию на уровне HR . Это может определить руководитель группы прогов ЕСЛИ он САМ программист .
Когда отчет перестанет работать на количестве сотрудников свыше нескольких сотен ,или начнет тормозить всю систему , или не сможет обработать новые типы удержаний , и придется писать новый  , или полностью переписывать старый за те же 10 часов  , эти три часа аукнутся .

(383) а стандарты разработки от фирмы 1С отменили? Я ни разу не наблюдал, чтобы конфигурации (не от фирмы 1С) хотя бы на половину соответствовали этим стандартам.

(385) это достаточно выявить на стадии собеседования. Например, пригласить опытного гуру для проверки компетенции соискателя. Не обязательно, да и крайне не желательно оценивать способности сотрудника уже "в бою".

(384) Передергивание
Ты видимо вообще не прог , а если и прог на серьезном проекте никогда не работал .
При чем тут распи..дяи ? Не специалист даже задачу правильно поставить не сможет сотрудникам.
Есть разница между ТЕХНИЧЕСКИМ заданием и ПРОЕКТНЫМ

(388) а для нормальной постановки задания необходимы навыки программирования? А как же тогда пишут тех. задания?

(386) Они слишком общие это раз
Следствие того что руководитель группы эффективный менеджер а не программист это два
Должны быть внутренние стандарты это три
(387) Достаточно если берется в штат фикс на поддержку
Совершенно не достаточно для работы в группе , смотри про самоорганизацию групп программистов выше

ТЕХНИЧЕСКОЕ задание может написать только программист , то что во многих случаях НАЗЫВАЕТСЯ техническим заданием представляет собой проектное задание
Разница как между руководством по эксплуатации автомобиля и руководством по ремонту и техническому обслуживанию

Ладно, посмотрим в сторону фирмы 1С. Насколько я знаю (поправьте, если неправильно знаю), в фирме 1С иерархия небольшая. Работают они так: есть руководитель проекта, который отлично разбирается в учете и возможно совсем не разбирается в программировании, есть куча аналитиков на подхвате, и есть группа разработчиков, которые самостоятельно пишут для себя же тех. задания, сами же решают, какие объекты использовать (разумеется, придерживаются стандартов и регламентов), сами же анализируют, как лучше делать, и ни кто над ними не ходит и не нудит, мол "делай так, это сюды..." Если удается целые типовые конфигурации писать, то почему в маленьком проектике-то нужно каждому разработчику сопли подтерать по вопросам правильно/не правильно он делает?

Не путай клочок бумажки от главбуха или манагера с "хотелками" , с техническим заданием программисту работающему в группе на проекте .
Разные проги могут работать над разными документами (или блоками) использующими общие данные и взаимодействующие между собой . В техническом задании как раз оговаривается архитектура общих данных , порядок взаимодействия ,  стандарты (например по транзакциям ) и т.п.
Не программист его просто НЕ СМОЖЕТ написать

Вот так аксиома перерастает в холивар на тему "может ли кухарка управлять государством" :)

(390) в этих стандартах есть все, чтобы избежать ошибок и сделать конфигурацию гибкой и легко анализируемой. Там есть требования ко всему: и наименованию общих модулей, и оформлению кода, и по интерфейсу. Чего там не хватает, что приходится "выдумывать" на месте?

(392) Глянул я тут последний релиз УТ11 , оно и видно что серьезно сэкономили на руководителе группы разработчиков :(
Стандарты и регламенты кстати кто то должен разрабатывать
А кто говорил о маленьком проекте ?
Типовые конфигурации вовсе не верх сложности , а про оптимальность их кода в приличном обществе прогов вопрос лучше не поднимать :)

(393) так если в самой фирме 1С так работают над ниипаться большими конфигурациями, то почему также не может быть на маленьком проекте?

(391) что ты понимаешь под техЗаданием ? о_О

какую строчку написать ?

четыре сотни (!)

(394) Люди которые проголосовали "Не должен" , здесь просто игнорируют посты где описываются ТЕХНИЧЕСКИЕ аспекты . Они видимо и относятся к этой категории :)

(396) я не говорю о совершенстве типовых. Но по сравнению с тем г., которые оставляют за собой внедренцы (корявый и совершенно не внятный код, ни одна процедура не содержит комментариев, непонятное использование объектов (чуть ли не по назначению)) - типовые конфигурации верх мастерства.

(398) В техническом задании ДОЛЖНА быть описана структура данных , и как минимум базовые алгоритмы а так же разъяснены ТЕХНИЧЕСКИЕ вопросы . Техническое задание не должно допускать двойного толкования

(402) Какие руководители групп программистов - такие и внедрения :)

Я пока не встречал ни одного отраслевого решения, ни одного внедрения типовой, ни одной нетленки, в которых были бы выдержаны "поверхностные" стандарты разработки от фирмы 1С.

(404) если честно, я даже не видел этих руководителей групп программистов.

Условно
Архитектурный проект - проектное задание
Конструкционный чертеж - техническое задание
Технологическая карта - журнал разработчика

(403) зачем?

(401) Люди которые управляют подчиненным с помощью пристегивания к батарее, паяльника и утюга, докажут тебе обратное :)

(403) а программисты не могут поучаствовать в составлении тех. задания?

(395) Ни в одном стандарте нет кейсов и опыта по решению задач оптимизации. А в реальной жизни напарываемся и на учет аналогов и на построение прогнозов и на оптимизацию ассортимента выпуска на основании ассортимента материалов. Разработка структур данных и эффективных алгоритмов - дело старшего. Мне вон тут двигали идею копипасты функционала для 3-х документов - так же проще. Естественно проще, но мне нужен продукт на сопровождение и развитие которого понадобится минимум усилий группы, а не решить текущую задачу за 60 часов.

(0)
Должен ли прораб уметь сам выполнять отделочные работы?
Должен ли офицер уметь стрелять из автомата?
Должен ли зав. травматологическим отделением уметь ставить клизму?
Должен ли главбух уметь выписать приходный кассовый ордер?

Даже если руководитель группы не программирует каждый день, то уметь программировать он точно должен.

(109) Вот, кстати, именно Билл Гейтс (по воспоминаниям того же Спольски) очень глубоко вникал в технические проблемы.
(341) Не согласен. К ошибкам программистов надо относиться не как к случайностям. А почти как к основному результату их труда - ошибки совершают все, хотя с опытом их и может становиться меньше.

(410) могут... но у них стек задач обычно забит и нет времени отвлекаться на чужую работу

(405) Во первых стандарты могут быть собственными (в той или иной степени)
Потому и не видел внедрений нормальных потому что не видел нормальных руководителей групп или РП которые их назначают или нанимают. Ну что можно сказать не повезло :)
Я вот то же за более чем десять лет в ИТ не видел ни одного менеджера или бухгалтера которые могли написать нормальное техническое задание , в лучшем случае хорошее проектное (но я верю они существуют , просто мы не пересекались не разу)

(413) а нафиг в проекте нужны специалисты, у которых куча дел параллельно? Про врабатываемость что-нибудь слышали?

(410) Могут а в ряде случаев должны (в узкой области приложения они могут превосходить руководителя группы и как правило и превосходят) но после принятия решения только исполнять в его рамках , если что то не идет или выявлена ошибка на стадии проектирования (все ошибаются) , то переписывается и дополняется техническое задание а потом уже код , иначе начнется хаос.
(408) Потому что оно ТЕХНИЧЕСКОЕ , а не проектное , или просто пожелание или баг-лист или что нибудь подобное

(416) заказчик описал проблему "прогу"
зачем ему что-то писать ?

(415) +100

такие "проекты" затягиваются на долгое время, ибо человек не робот и на "вспомнить" уходит время

(360) Тому, кто будет систему сопровождать это абсолютно не по барабану.

(415) раньше на военном флоте была традиция . Когда капитан затруднялся в принятии решения собирались офицеры в кают-компании , и спрашивалось их мнение. Причем первым мнение высказывал самый младший по званию , что бы более старшие не задавили своим авторитетом , после обсуждения капитан принимал решение , и потом все - только исполнять.
Одновременно приветствовалась и инициатива и не зашоренность мышления и дисциплина

(414) да что у вас за представления-то такие... Посмотрите на любую серьезную организацию, там сотрудники не зажаты бюрократией со всех сторон, они получают задания и возвращают их решения, и никто им не указывает на каждом шагу, как надо правильно делать. И ведь... фантастика! у таких людей колоссальная отдача. Это я не с потолка взял, это Вы прочтете в любой книге по мотивации и управлению персоналом.

(417) На "проектиках" может и проканает , или когда прог один , при усложнении задачи нет

(421) Бюрократия зло - отсутствие бюрократии катастрофа
На саяно-шушенской тоже вон блин свободно отключили нагрузку от генератора , хренли документацию читать , инженер эксплуатационщик может идти нафиг , что он тут отсвечивает

(422) или ты считаешь, что это тех задание потом облегчит следующему прогу, который придёт после первого ваять своё ?

(415) кто сказал "параллельно"?
(421) это не группы программистов, это тандем руководителя и исполнителя. Много тандемов, но не группа. Группа программистов это либо затяжной проект, либо срочный. Мы сколачиваем группы чаще под срочные - программирование одной задачи в n потоков. Один специалист просто не может держать в уме разработку всего проекта. А вот звено успешно разрабатывает 5 разных документов, 10 отчетов и обмен данными с бухгалтерией. Причем разрабатывает параллельно. Стоит руководителю упустить контроль - и начнутся перекосы в функционале. Добро пожаловать в мир Agile.

(421) Ты описал цирк , но даже в цирке есть нормативы техники безопасности :)
Без четкой иерархической структуры , и нормативных документов по исполнению работ , прописанных должностных обязанностей , инструкций определяющих ГРАНИЦЫ инициативы , в такой конторе можно будет только пилить и откатывать . Правда сейчас это норма основ бизнеса , по этому я не удивлен

(425) +100

(423) там где возможно - бюрократии должно быть по-минимуму. Ибо бюрократия за собой непрерывно влечет:
- подавление инициативы;
- снижение оперативности;
- вклинивает в процесс совершенно не нужные сугубо личные цели (кто-то хочет почувствовать себя полководцем, кто-то хочет утереть нос коллегам и пр.);
- проволочки.

(425) контроль также должен быть вмеру. Нечего на каждом шагу каждому в попу заглядывать.

(424) И это в том числе а так же посмотри (354)
Когда разработка централизована на одного спеца техническое задание вообще может не потребуется , достаточно проектного , но если разработка идет параллельно без него не обойтись , мы говорим о группе (которая в свою очередь может состоять из микрогрупп 1-2-3 чел) что подразумевает параллельность , не будут же 4 человека ОДНОВРЕМЕННО писать одну процедуру . Но вызывать эту процедуру будут и другие

(428) Демагогия

(426) это не цирк, а быт крупных организаций. Верится вам или нет, но могут группы работать сплоченной командой и без пристального сувания носа руководителем во все дырки.

(430) в очередной раз переспрошу: а эти группы самостоятельно договариться между собой никак не смогут? Непременно нужен пастух?

(429) Контроль и обзор кода руководителем проводится каждый час в независимости от того работает специалист 1 или в паре. Добро пожаловать в мир Agile и XP в частности.

(428) если Вы для себя откроете научный менеджмент, то там найдете: не стоит зажимать сотрудника в рамках, он должен чувствовать свою свободу и свою значимость, с чем человек сможет справиться самостоятельно - то нужно целиком доверять ему, и не нужно ставить над ним наставника. И в книгах по менеджменту, управлению персоналом о мотивации это встречается каждые пять страниц.

Ваши представления устарели...

Не смогут или очень ограниченно .
В программировании "Как нибудь так вроде как бы" не канает , это математика и четкая структура .
Если хотите получить программу с нечеткой логикой и кнопкой "Посчитать все как я хочу" можете попытаться пустить все на самотек.

(436) Прежде чем открывать для себя научный менджмент надо открыть для начала основы прикладных знаний
Эффективные менеджеры на марше блин

(430) они между собой не вась-вась ?
зачем нужна прокладка в лице руководителя ?

(434) и Вы этим пользуетесь? Каков процент текучки у Вас?

(433) как они договорятся, если по графику соседнее звено должно начать использовать их код завтра, а другое - послезавтра. И это непрерывный цикл, работа одних завязана на работу других. Нет времени на раздумья, нет времени на переговоры, все это обязанности руководителя процесса. От исполнителя нужны результаты. Идеально соответствующие спецификациям и стандартам. Более того, ни один человек не занимается рутиной... потому что старший группы - неиссякаемый генератор идей. А исполнители - полевые исследователи воплощающие идеи в жизнь. Эффективность исполнителя и его творческий потенциал в такой схеме умножены на потенциал руководителя. Сложно. Трудно. Голова кругом. Но бешеный драйв, лихость и ошеломляющие результаты.

(439) Моя группа работает одним составом уже 2 года.

(438) ну как же, специалисты по определению тупы и не организованы ;)

(441) ай да молодец вы))). За 2 года не одного увольнения это здорово.

(442) о_О
и давно ?

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

(441) не знаю, что у Вас за группа. Но вот честно, если бы в процессе работы, каждый час, ко мне подходил руководитель, отодвигал меня от компьютера и начинал смотреть, чего же я там наделал, я бы ушел с такой организации нафиг, какие бы хорошие зарплаты там ни были. Я что, сильно глупый или неспособный, что мне нужно постоянно в попу заглядывать, дабы я чего не вытворил? И думаю меня многие поддержат.

(443) Это не я молодец, это коллектив опупительный.

(444) не знаю, я таких почти не встречал. Но судя по всему, некоторые только с такими и работают ;)

(446) Так тебя на аркане никто и не тянет. Вот только нормальный руководитель не позволит из за звездности одного сотрудника запороть работу всех остальных. Легко работать одному, а вот осознавать, что твой код уже завтра нужен твоим коллегам - гораздо сложнее. И специалисты прекрасно понимают, что лучше перебдеть, чем потом сотни косяков исправлять за свой счет.

(446) Не надо путать заглядывание в попу каждый час с code review или обсуждением того, как будет реализовываться тот или иной функционал.

(449) ну и опять же спрошу: а между собой программисты договориться не смогут?

(450) а "как будет реализовываться функционал", "код ревью" и прочее без руководителя никак?

(447) вы его сами сформировали?
Или взяли руководство уже сложившимся коллективом?

(452) Нет. Любая система прежде всего стремится к состоянию покоя. Если не будет возбудителя в лице руководителя - будет посредственный продукт. Посредственность не нужна.

Я несколько лет участвовал в разработке системы, где в качестве руководителя проекта выступал главный бухгалтер, правда сразу скажу, что главный бухгалтер не обычный - таких главбухов еще поискать, после общения с такими начинаешь понимать насколько интересна при определенном подходе профессия бухгалтера и постановщика управленческого учета. Этот бух не умел программировать, однако структуру данных конфигурации представлял в совершенстве, причем конфигурации не из десяти документов, по количеству объектов конфа приближалась к УПП, я как программист уже давно потерял единый взгляд на работу и взаимосвязь объектов - этот главбух, в отличие от меня, представлял всю конфу в совершенстве. И великолепно выдавал задания на разработку - я за свою жизнь встречал всего двоих таких человек, с которыми было бы так приятно работать на проекте и, замечу, оба из них были бухгалтерами. Чисто технические руководители, т.е. именно чистые программисты как раз оставляли за собой массу непоняток и проблем...

(452) никак , не возможна саморганизация , если задача хотя бы более менее сложная

(451)Пока их 0, 1 или 2 - легко договариваются. Когда 3 и более - уже всё может быть не так уж и просто. Когда 10 - точно не смогут, если все будут делать "каждый своё".
Приходится разделять между собой функции - как программирование, так и управление. Обычно выделяется руководитель группы. Чаще всего и логичнее всего это приводит к модели "играющий тренер" или "хирург" (см. Брукса). Тут нет речи о несвободности в выборе решений, но изменения в сложной системе, где много взаимозависимостей нельзя принимать в одиночку.

(455) Исключение лишь подтверждающее правило :) Повезло

Я пришел в коллектив рядовым, после меня еще приходили люди. Сейчас потихоньку перехватываю обязанности старшего программиста чтобы разгрузить РП. Клиентов стало больше, и он уже не успевает.

(0)Универсальный ответ на ВСЕ подобные вопросы:
"Плохой руководитель все делает сам. Хороший руководитель - знает кому что можно поручить".
Другими словами - руководитель должен хорошо разбираться не в 1С, а... в ЛЮДЯХ. Именно те, кто прекрасно разбирается в людях, может за пару минут оценить (по правильным вопросам, тестовым заданиям, поручениям, по ответам, действиям подчиненного и другим косвенным признакам) определить действительно ли разбирается человек в той области, в которой сам руководитель "ни бум-бум"?

(457) И даже в колективе из 3-х человек , скоро появляется неформальный лидер который тащит функции ведущего прога (руководителя группы) , и остальные ему подчиняются ЕСЛИ заинтересованы в успешном завершении проекта

(454) руководитель подталкивать должен. Но не на каждом шагу! Не должен он следить за каждым движением подчиненного.

(459) Понятно. я просто сначала подумала, что вы руководитель.

А как вы считаете какими чертами характера должен обладать эффективный руководитель?

(452) В простых системах, пока разработчиков 0-2 - можно. Если разарботчиков 3-4, то может быть и возможно, но не всегда. Если разработчиков больше, то без структуры в группе - невозможно. Для небольших групп простейшая форма структуры - как раз и будет выделенный руководитель.

(458) В чем же исключение - дожив до сорока лет я не встретил ни одного хорошего программиста руководителя проекта, все из них не могли внятно изложить задание, нет не алгоритмы, это уж извините я сам решу как программировать красивее и эффективнее, а именно правильно и понятно изложить постановку задачи. А вот встреченные мной компетентные бухгалтера с хорошим знанием как бух учета так и структуры конфигурации (последнее подчеркиваю особо) это сделать могли... Так что, по моему, это скорее правило, а не исключение...

(462) Нездоровый у тебя взгляд на производство ПП. Мы ВМЕСТЕ делаем продукт. Мы все будем его авторами и будем гордиться продуктом целиком. Чтобы им гордиться мы должны делать классные вещи. В одиночку сделать классную вещь - нельзя. Это - аксиома. Поэтому каждый сотрудник ждет обзора и хочет критики результатов. Чтобы стать лучше. Чтобы каждый следующий проект был лучше предыдущего. Чтобы развиваться.

А ты хочешь сделать цацку, и чтобы похвалили тебя одного и другим в пример поставили: "Смотрите какую он цацку запилил. один! Учитесь все у него как работать надо!"

(460) Руководитель проекта - несомненно
Руководитель группы - в первую очередь профильный спец , а если он при этом разбирается в людях , и владеет принципами управления - это отличный руководитель группы
Ведущий прог - не обязан уметь управлять , он решает чисто технические вопросы
Руководитель группы и ведущий прог часто совмещаемые должности , в группах до 10 человек

(465) вот я тоже самое пытаюсь тут доказать добрую половину обсуждения.

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

(465) Тема не об РП, а о старших программистах и системных архитекторах. РП - другой уровень компетенции в принципе.

(462) За каждым движением - не должен, конечно. Уже для 5-6 программистов в группе в лучшем случае получится только поверхностно отслеживать все вносимые изменения (но вполне можно отслеживать критичные решения и еще программировать).

(465) Тема топика не руководитель проекта а руководитель группы программистов , эти понятия часто путаются , на самом деле это совершенно не одно и то же

(466) из каких моих слов последовало, что каждый захочет быть пупком проекта и в этом его надо поощрять? Нет уж, это Ваши домыслы.

(469) Ты успел чуть раньше :)
Как можно обсуждать вопросы квалификации руководителя (проекта и группы) если многие даже не понимают отличий ?

(463) Звучит глупо, но руководитель должен быть именно руководителем. Воля, умение слушать, внимательность к подчиненным и умение работать бритвой Оккама. Обязательно уметь решать проблемы. Вообще в книжке "Как пасти котов" очень хорошо все разложено ;) рекомендую

Зажимайте и дальше всякую инициативу своим вездесущим контролем и руководством. Я так работать никогда не соглашусь. Нафиг нужно.

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

(472) из тебя так и прет "я сам знаю, что мне делать с моими файлами". Из всех постов видно, что для тебя важнее не продукт, а твое авторство над ним. ИМХО конечно же. Я могу и ошибиться - интернет все же. Но мне кажется ты на подсознательном уровне хочешь самоутвердиться а не продукт сделать. Извини за прямоту.

(475) Ну а ты похоже никогда и не работал на серьезных проектах , а с таким подходом никогда и не сможешь (что руководителем что исполнителем)

(477) опять ты опередил :)

Должен, иначе это будет руководятел.

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

(476) ага... 1Сников не считают программистами не потому, что 1С плохая или программировать не умеют. А потому, что технологий производства ПО практически не знают. Sadovnikov, где ты??

(468) да ну!

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

Ваша середина прошлого века давно прошла, опоздали Вы со своими методикани управления людьми...

(481) Армия самое устойчивая структурная организация придуманная человечеством , когда все разваливается (стихийное бедствие) армия продолжает функционировать
В великую отечественную серьезный перелом в КАЧЕСТВЕ ведения боевых действий произошел в 43 году , когда серьезно была изменена структура управления и принятия решений , отменены комиссары (они стали ЗАМЕСТИТЕЛЯМИ по политической части) , четкое единовластие и иерархия

(483) да никто и не возьмет

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

(476) плох тот руководитель, который на себе всю работу волочит. Прежде всего руководитель:
- планирует;
- координирует;
- согласовывает с "верхами";
- анализирует;
- контролирует (но никак не надзирает и советы раздает).

Не возможно воевать без дисциплины и цепочки командования
Не возможно создать программный комплекс (не утилитку или отчетик) без соблюдения современных технологий производства ПО . СОВРЕМЕННЫЕ технологии как как раз и предусматривают выше описанную иерархию и порядок взаимодействия

(485) так я и другим посоветую с Вами не связываться. Ну его накуй людям страдать в команде, где за эталон армию держат...

(487) Устал уже . Не путай руководителя проекта с руководителем группы .
(486) Руководитель группы в первую очередь проектировщик и архитектор системы , то есть человек который превращает пректное задание в техническое и определяет стандарты реализации , ведущий программист отвечает за воплощение архитектуры в коде

А-а-а-а!
Срочно, прям бегом на курсы по менеджменту! А то так и помрете со своими представлениями "чем больше ударов кнута, тем быстрее и лучше работают".

(490) Что тут говорить: руководить программистами может только программист. Видел случаи, когда это делает плохой программист, над которым сотрудники смеялись.
А воообще - не программист, а например, партийный работник, Огруцов такой - смешно.

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

(490) зачем тогда нужны программисты? Крутиться под ногами у руководителя группы? Ведь он сам всю самую важную часть делает, так и остальное неплохо сварганит...

(494) Программисты воплощают проектную архитектуру в коде

(492) "руководить слесарями может только слесарь", "руководить сварщиками может только сварщик" - давно изжившие себя представления.

(495) А художник - в виде картины. И руководить художниками могут люди, не умеющие рисовать...

(496) Приведены примеры нетворческих профессий, заменяемые ныне автоматами и станками с ЧПУ.

А вот конструкторами руководят всегда конструкторы.

(495) а с проектированием структуры им не справиться?

Потихоньку мы дошли до того, что руководить группой должен не просто умеющий программировать, а самый опытный программист (!)

(500) Руководят всегда самые опытные, что тут нового?

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

Ну если армейские аналогии не устраивают давай возмем киношные :) Аналогии конечно приблизительные но съемка кино это сложный и отлаженный процесс
Продюсер - руководитель проекта
Режиссер - руководитель рабочей группы
Директор картины -  на очень больших проектах администратор проекта
Оператор - ведущий прог (приблизтельно :) )
Композитор - приглашенный узкий спец :)
Остальные - актеры , гримеры , рабочие сцены - исполнители

(500) В маленьком коллективе часто так и бывает - функции руководителя и архитектора совмещаются. Но уже от 6-7 программистов руководитель и архитектор могут быть разными людьми. Это не отменяет то, что руководитель группы должен чётко понимать все изменения, но он уже не может сам принимать архитектурные решения.

(500) Ну наконец то , да , как правило самый опытный , не обязательно лучший или способный , но самый опытный

(500) Именно. Руководит человек на порядок, а то и на 2 лучше разбирающийся в предмете. Его уровень таков, что просто преступно тратить его время на написание прикладного кода. Его время нужно тратить на разработку архитектур, инноваций, решение проблем и прорывы кризисов, а никак не на прикладные реализации. Он уже может не помнить методов объектов, но он знает правила трансляции запросов в СУБД. Он может написать неэффективный цикл, но разработанные им спецификации позволят реализовать максимально масштабируемю, понятную и расширяемую архитектуру. И ревью кода нужен ему как средство остаться на грешной земле и не уйти в астрал.

Ну вот, еще дальше продвинулись, теперь руководитель должен быть богом ремесла...

(507)Вот зачем всё время передёргивать? Нет, не должен быть "богом ремесла". Просто в маленькой группе часто приходится совмещать роли. Для групп 2-6 человек роль архитектора и руководителя группы часто хорошо совмещается. В группах побольше - с одной стороны административной работы больше, с другой - технические решения сложнее и эти роли распадаются.

(506) очень спорный момент, что руководитель должен сосредотачивать все идеи и все тонкости на себе. Как человек мало-мальски разбирающийся в типологии личностей, я Вам скажу, что гинеальные идеи рождают те люди, которые совершенно не способны на рутиную работу (классический пример - рассеянный профессор), и наоборот, человек привыкший уделять большое внимание деталям не способен на генерацию идей. Они видят мир по-разному - первый смотрит на мир широко и глубоко, а второй видит его в виде мозайки...

(503) Аналогия эта ошибочная.
А вообще, как оргнизована работы программистов была в США, описано в книге Брукса "Мифический человеко месяц".
Там бригаду программистов возглавляет главный программист, который ВСЕ ПИШЕТ САМ.
А у нас еще и сейчас употребляются советские схемы, когда во главе проекта ОБЯЗАТЕЛЬНО ставится некомпетентный человек,  так называемый, руководитель.

(509) Рассеянный программист - сколько угодно, но только не в профессии.

Как то в рамках написания хитрого блока учета , сбросил программисту ТЗ на хитрую таблицу соответствий по соотношению многие к многим , он изучил и начал задавать вопросы зачем так сложно , тут и тут можно упростить и т.п. Была определенная запарка , работали в три потока , и я ему сказал - не думай , делай , остальные ждут , объяснять некогда . Он подобиделся но сделал все как надо.
Через пол года  (а он штатник ИТО) он подошел и и спросил как я догадался что именно эта структура окажется самой оптимальной в рамках дальнейшего развития системы к которой в данный момент подошли , и она подходить идеально и переделывать ничего не надо.
Проектировщик просто смотрит вперед и вширь , и должен такие вещи предусматривать

(510) все пишет сам не совсем относится к тому, что работает бригада программистов, и каждый из них, прежде чем написать новую функцию, все согласовывает с руководителем группы.

(511) так необязательно на месте "рассеянного гения" должен быть программист. Программист как раз (если прирожденный) видит в первую очередь детали, и с трудом воспринимает целостную картину.

(510) Поэтому руководитель группы и должен быть программистом
Читал и перечитывал , кстати для минимизации потерь времени прогов по взаимодействию друг с другом и вводится понятие сеньора
И он пишет о том что работа (потоки) не может быть разделена произвольно , но не отрицает необходимости разделения , просто определяет общие принципы разделения.
Книга конечно - фундамент современных технологий создания ПО.
Alexandr Puzakov рекомендуется к прочтению

(513) У американцев (40 лет назад, когда писалась книга), один программирует, у него есть второй пилот, который иногда подменяет, знает все коды, но сам не пишет.
Остальные - тестируют, пишут документации. Еще там может быть "руководитель группы" - специалист по системам и структурам - он ПОДЧИНЕН программисту.

(509) А я о чем? Руководитель - не пишет кода. Его задачи - архитектура. Ревью кода - это только чтение. Для обмена опытом между исполнителем и руководителем. Исполнитель может найти интересные алгоритмы, которые отложит в копилку концепций руководитель. Руководитель может указать на неоптимальность. В конце концов переключение с разработки к ревью может вывести обоих из ступора идей. Кроме того руководитель получает объективную картину процесс работы и представление о том, насколько его архитектура смогла облегчить труд программиста, а программист получает дополнительную уверенность в том, что он не чушь пишет, получает единомышленника. Таким образом руководитель при играх с архитектурой не оторван от реалий технологических средств и не пишет фантастических романов вместо спецификаций. А программист, уверенный в своем руководителе, получает прикрытый тыл. Знает, что коллеги ни свинью в код не подложат, ни архитектор фигню не придумает, и знает, что проблема проекта - не его проблема, что у него есть с кем ее порешать. Еще раз - в группе каждый должен заниматься своим делом. Не должен каждый участник знать все обо всем и самостоятельно утрясать проблемы с другими участниками. А то будет как в думе - каждое решение должно пройти 4 чтения.

(514) Программист - это человек, которые моделирует реальность, тем самым ее упорядочивая.
Тот, кто " с трудом воспринимает..." - не программист или еще не программист.

Ладно, мне сейчас некогда, потом продолжим дискуссию.

Договоритесь между собой ;)

(517) Руководитель - ПИШЕТ коды. Поэтому он все держит в своих руках.

(516) Брукс хорош... но не для каждой технологической базы. "Операционная бригада" - безусловно один из эффективнейших способов построения качественной системы. Но данная система не может параллельно решать задачи разработки. Распараллелить проектирование и документирование - да. А вот распараллелить разработку уже нет. Поэтому Брукс - это как алфавит. Мало знать буквы, надо еще и слова собирать причем к месту.

(510) нет. Вот как раз примерно того, кто видит мир мозаикой, будет талантливый программист ;)

Он может тупить в компании, но дай ему листинг когда, и он быстро найдет в нем ошибку :)

(517) Согласен , хотя на практике иногда приходится (и хочется) писать код , но идеал не достижим :)
Тут в ветке многие говорят о руководстве но путают должности , функциональные обязанности и даже административные и функциональные линии управления
Кстати по административной линии нижестоящий - подчиненный
По функциональной - исполнитель
И это то же разные понятия

Когда = кода

(520) Ведущий программист - пишет
Руководитель группы - как правило нет , бывают исключения в зависимости от ситуации (сроки , состав группы , совмещение должностей , стиль управления , конкретная задача)

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

(526) Согласен , но мы живем в реальном мире :( Приходится
Конкретный пример
В компании где работаю идет плановый перенос функционала с клюшек на снеговик (с соответствующим его расширением), неожиданно вне графика по производственной необходимости потребовалось СРОЧНО перенести определенный блок синхронизации , структура на данных на восьмерке уже создана и в целом совместима . Переписывать ТЗ и разъяснять задачи займет больше времени чем я сам напишу этот блок в новой учетной системе , потому что ранее сам писал его в старой (и мне объяснять ничего не надо я сам его разрабатывал и реализовывал).
Написал код , блок запущен и функционирует, ТЗ перписано задним числом , задача по оптимизации и вылизыванию доведена да исполнителя (пусть и поучится заодно глубоко работая с чужим кодом)

(527) Ну да, годный руководитель должен быть готов в любой момент закрыть брешь в проекте. А когда она образуется - никто не предскажет.

Кроме того достаточно часто пишу "черновой" код для себя что бы проверить как оно в принципе будет работать еще на стадии проектирования , но как правило этот код в финальные версии не попадает

на основании этого можно понять какие затыки могут возникнуть у программиста на стадии практической реализации , прямо в ТЗ дать рекомендации и уточнения

имхо

(0) А разве можно однозначно ответить на вопрос? Бюджет проекта определяет численный состав участников. Функции, необходимые для выполнения проекта должны быть поделены между ними.

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

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

(533) есть области управления в котрых профессиональная специализация управленца не так критична , программирование , точнее создание ПО к таковым не относится , слишком специфично.
Или например капитаном корабля  (даже гражданского) НЕВОЗМОЖНО стать не побывав в шкуре матроса , достаточно посмотреть подготовку курсантов мореходки. Потом карьерная лесница штурман-вахтенный офицер-помошник-старшийпомошник-капитан . А ведь капитан корабля (какого нибудь лайнера) это административная должность ВЫСОКОЙ ответственности .Как говорят на флоте старпом управляет кораблем , капитан им командует. Чето не видно на капитанских мостиках высокоэффективных менеджеров .

(535) Да не спорю. Но чтоб руководить программистом руководитель хоть раз должен написать прогу  на чем угодно но вот если в 1с что то писал это будет токо гуд

(536) Что бы руководить группой программистов на серьезном проекте , нужно как минимум в одном таком же проекте (а лучше не в одном)поучавствовать в качестве рядового исполнителя , а это уже достаточно серьезный уровень кодера

На чем мы остановились.

(534) Вообще-то в теме речь о руководителе разработки, а не о руководителе программистов.

> 2-3 спеца могут договорится между собой 4-5 уже с трудом , больше уже не могут.
Эта фраза, кажется, больше говорит о том, что в таком коллективе умение начальника программистов программировать не самое главное умение. :)

(539) Группа разработки это и есть в первую очередь группа программистов
Вот именно что главное , потому как они договариваются не о девочках и не о том куда после работы двинут , а принципах и способах реализации програмных решений . Не специалист в их споре поймет одно слово из трех , как он примет решение , если один счтаеет что нужно испльзовать n-мерный массив объявив его как глобальную переменную , а другой несколько таблиц значений локально с динамическим сохранением в справочнике

У каждого варианта есть плюсы и минусы , выбор решения зависит отмножества факторов о значительной части которых исполнитель и не знает (да и не должен знать что бы мозги не засорять)
1. Производительность
2. Потребление аппаратных ресурсов
3. База единая или будет распределенка
4. Если будет распределенка , перферийные на скуле или файловые
5. Сложность реализации
6. Сложность дальнейшей поддержки сторонними спецами
7. Будут ли остальные пользователи использовать промежуточные данные из масива

И т.д , И т.п

(540) Да вот не всегда в его функции входит принятие решений. А вот организация выполнения работ входит всегда.

> один счтаеет что нужно испльзовать n-мерный массив объявив его как глобальную переменную , а другой несколько таблиц значений локально с динамическим сохранением в справочнике

а) Организуется взаимная проверка кода. По разногласиям организуется обсуждение (мозговой штурм) с выявлением достоинств и недостатков. Принимается решение о исправлении того или иного участка кода.
В каком месте этого процесса ему надо уметь пограммировать?

б) Он сторонник использования n-мерных массивов, так как когда он программировал это было круто. Поэтому другие варианты не принимаются.
А может надо отобрать у него функцию принятия решений?

объясните отсталому чем отличается руководитель разработки от  руководителя программистов?

(543) Ви слепой? Не различаете слова разработка и программист? :-)

(542) Коллективное решение это не решение это согласование , решение должно приниматься единолично , потому что групповая ответсвенность это безответсвенность .
>>В каком месте этого процесса ему надо уметь пограммировать
Эффективный менеджер знает что такое n-мерный массив , и какие траблы он может вызвать ?
>> Он сторонник использования n-мерных массивов, так как когда он программировал это было круто. Поэтому другие варианты не принимаются.
Ну значить группе не повезло с руководителем , или РП назначил своего племянника на должность :)
По крайней мере ему и отвечать если он ошибся в выборе и не учел какой либо фактор

(544) слова то отличаю но на деле именно в 1С ведь это почти синонимы.

(543) руководитель разработки = руководитель программистов
Руководитель разработки <=> руководитель проекта
Руководитель разработки <=> ведущий программист (сеньор)

(547) Спасибо примерно так и представил, думал просто на деле я обычно РПроекта и и РПрогов это одно лицо и их почти не делят как две позиции. Значит я не в курсе. ну видимо в больших проектах типа УПП есть такое.

(0) Насчет тренера по плаванию, это наверное мегаисключение

(548) В малых рабочих группах на практике Руководитель разработки совмещает обязанности с ведущим программистом ,  в таких случаях очень сложно организовать параллельную разработку ,но в малых группах она используется достаточно редко .
Рукводитель разработки досстаточно редко совмещает свои обязанности с обязанностями руководителя проекта , потому что руководитель проекта это прежде всего административная должность а не техническая . Руководитель проекта отвечаетет за
Координацию между разработчиками и заказчиками
Подготовку проектной информации в предметной области
Координацию между проектами
Административное управление проектом
Финансовые вопросы
И т.п.
Вот он может не быть программистом (хотя неплохо бы иметь представление) , но должен быть в первую очередь управленцем

(506). "ревью кода" - пипец, очередной эффективный менеджер бросающийся иностранными терминами.

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

Вот чем должен руководитель проекта заниматся , и тут нет ничего от программирования

(313) суть ветки :)

дефки спорили на даче...

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

(554) а спора то никакого и нет , те кто утверждает что руководитель разработки не должен уметь программировать просто не работали на больших проектах в группе , иначе бы не путали понятия см (523)

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

(556)РП должен садиться за клаву?
Это плохой РП...

(554) огласите список, пжалста.

(557) плохой руководитель не знает предметной области, плохой руководитель боится клавиатуры, это не значит, что он все должен знать, уметь и делать

(557) А причем здесь РП ? Он же не руководитель разработки и не ведущий прог .

(560) Читай (556)

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

(556) а сортир за уборщицей руководитель мыть не должен, если та плохо помыла?

(561) А там не уточнено какой руководитель , может начальник транспортного цеха :)
Хотя раз отвечает за проект тогда РП , тогда не должен .

(562) они равны. Обои стоят на одном уровне иерархии, оба функциональные руководители и обои подчиняются генеральному директору. На одном уровне иерархии не может один быть главнее другого.

(565) они стоят на разных уровнях иеррархии , финансовый директор выше в уровне иерархии компании хотя бы потому что входит в совет директоров и влияет (определяет)  стратегию компании, но главный бухгалтер и бухалтерия не должна подчинятся финдиру ни административно не функционально

(566) с чего это вдруг финансовый директор входит в совет директоров? То, что экскаваторщик управляет экскаватором, ни сколь не делает его главнее водителя ген. директора. Директор по персоналу определяет стратегию по развитию, движению, увеличению/уменьшению персонала, может он тоже главнее генерального директора будет?

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

(551) вброс незащитан

(567) А с какого фига финансовый ДИРЕКТОР не входит в совет директоров , наравне с коммерческим директором , исполнительным директором , и пр. Совет директоров возглавляется генеральным директором .
Ты что вообще с с луны свалился ?

(568) Хочу посмотреть на такую компанию которая определяет стратегию без финансов :)

(563) должен, ибо, если плохо помыла,значит не того человека принял в команду

(570) а ничего, что в совет директоров не входит ни один из менеджеров компании? Совет директоров собирается из представителей акционеров...

(571) есть стратегия компании, "под ней" может быть, и обычно бывает стратегия производства, стратегия маркетинга, стратегия по персоналу... Каждая из них более широко разворачивает стратегию компании.

(545) О, правда, коллективного решения быть не должно. :) Вот так тогда.

Организуется взаимная проверка кода. По разногласиям организуется обсуждение (мозговой штурм) с выявлением достоинств и недостатков. ОН принимает решение о исправлении того или иного участка кода.

Кстати, такой подход мотивирует в краткие сроки поднять профессиональный уровень команды, если он недостаточен. Разумеется с введением премий за обнаружение ошибок и штрафов за злостное повторение обнаруженных ошибок.

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

плавно перешли с Брукса на Адизеса ;)

(573) Нахрен они там сдались , их на пятачок пучок , совет директоров ни в коей мере не собирается из представителей акционеров, совет директоров принимает достаточно оперативные решения , а собрание акционеров раз в год проходит (ну может два) , заколебешся их собирать :)
Согласно устава ( у нас по крайней мере) генерельный директор избирается (назначается) советом акционеров
Любой другой член совета директоров может быть назначен абсолютным большинством совета директоров
Совет директоров в лице генерального директора отвечет перед акционерами
Генеральный директор имеет на совете директоров 2 голоса (у всех остальных по одному) и абсолютное право вето

Ряд ключевых должностей не входят в совет директоров , и не отвечают перед акционерами , но имеют право совещательного голоса на совете в области их касающейся , как то начальник отдела маркетинга ,  начальник складского комплекса , начальник ИТО , главный бухгалтер

(576) ++

(576) ну это у вас, очевидно главный акционер компании запихал генерального директора в совет директоров. А так совет директоров - любые физические лица, назначенные представлять интересы акционеров в совете директоров.

(545) Взаимная проверка кода естественно применяется
И мозговые штурмы применяются само собой
И мнение исполнителей учитывается
Все это не имеет никакого отношения к принятию окончательного решения об архитектуре
МЫ посовещались и Я решил
Советовать , рекомендовать , доказывать можно до того как решение принято иначе будет разброд ишатания
Кстати и в архитектуре бывают ошибки (никто не безгрешен) , и сточки зрения последующего разбора полетов , руководидель разработчиков так же отвечает перед ними и огребает от них люлей :) Потому что он такой же член команды разработчиков просто делает несколько другое

(578) То есть если например необходимо построить например новый склад , вложив в это дело серьезные деньги , или например заключить договор с новым поставщиком на интересных условиях (или разорвать например договор по ключевому контракту) собирается собрание акционеров со всей страны ?
И этот человек борется против бюрократии ....

(578) Почитай в интернете что такое совет директоров для ОАО или ЗАО , и типовые права и обязанности генерального директора в рамках стандартного устава , и не выставляй себя здесь на посмешище

(580) такие решения принимаются на месте менеджерами организации, и возможно не самыми старшими менеджерами. Совет директоров созывается для решения более серьезных вопросов.

(581) читал, и даже закон бегло читал. Не увидел там ничего, чему противоречат мои слова.

Это вам стоит их внимательно перечитать. Генеральный директор - наемный работник, который представляет интересы компании, совет директоров - представители акционеров.

(583) в каждом чайнике свой кипяток...

(584) не гони, генеральный дир, вполне может быть и собственником, все зависит от организации

(586) а я где-то сказал, что генеральный директор не может быть собственником? Просто кое кто тут сказал, что финансовый директор входит в совет директоров.

(584) Не надо путать совет директоров с собранием акционеров , директора включая генерального обыкновенные наемные работники (ну не совсем обыкновенные конечно).
Акционеры не могут УПРАВЛЯТЬ компанией , они всего лишь вложили деньги в неё и назначить (или избрать из своего числа) управлящих (управляющего) . Акционеры как правило совершенно не компетентны в вопросах управления
(582) Вложения большого капитала серьезно скажется на дивидендах , менеджеры не могут принять такого решения , они НЕ ОТВЕЧАЮТ перед учредителями .
И вообще чето оффтопик начался , хоть новую ветку заводи :)

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

(588) может стоит почитать законы об ОАО и ЗАО?

Цитата из закона

Совет директоров — это орган управления в хозяйственных обществах (акционерное общество, общество с ограниченной ответственностью), который образуется путем избрания его членов на общем собрании акционеров АО/ общем собрании участников ООО.

Согласно ФЗ «Об акционерных обществах»[1] и ФЗ «Об обществах с ограниченной ответственностью»[2] синонимом понятию «Совет директоров» является понятие «Наблюдательный совет».

Членом Совета директоров может быть избрано любое физическое лицо, ДАЖЕ НЕ ЯВЛЯЮЩЕЕСЯ акционером или участником данного хозяйственного общества.

В то же время на членов Совета директоров распространяются следующие ограничения:
члены коллегиального исполнительного органа общества не могут составлять более одной четвертой состава Совета директоров общества.
лицо, осуществляющее функции единоличного исполнительного органа, не может быть одновременно председателем Совета директоров общества.

Основной функцией Совета директоров в акционерных обществах является осуществление ОБЩЕГО РУКОВОДСТВА деятельностью общества, за исключением решения вопросов, отнесенных законом к компетенции общего собрания акционеров.
для акционерных обществ с числом акционеров от пятидесяти и более — создание Совета директоров обязательно;
компетенция Совета директоров, предусмотренная в законе является для данного органа управления обязательной (кроме вопросов образования исполнительных органов и ревизионной комиссии, так как они могут быть отнесены уставом общества к компетенции общего собрания акционеров).
Количественный состав Совета директоров не может быть менее чем пять членов.
Для общества с числом акционеров более одной тысячи количественный состав Совета директоров не может быть менее семи членов.
Для общества с числом акционеров более десяти тысяч количественный состав Совета директоров не может быть менее девяти членов.

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

(590) читал..., чем ты хотел удивить?

Из этого следует что член совета директоров (включая генерального) управляет компанией и может не иметь акций (то есть не быть акционером)
Ответсвенность каждого директора перед акционерами определяется Уставом компании утвержденном на СОБРАНИИ АКЦИОНЕРОВ

Ты грамотный ? Совет директоров осуществляет руководство = руководство компанией , генеральный директор = руководитель компании

А теперь задумаемся над словами "члены коллегиального исполнительного общества не могут  составлять более четверти совета директоров"

(592) это не правило, но как правило, некомпетентные акционеры недолго такими остаются, в смысле акционерами...

(596) )))))))

(595) генеральный директор может как входить, так и не входить в совет директоров. Надо внимательнее читать.

(599) что это меняет?