Всем привет!

Ситуация: есть компания с колличеством программистов равным 3-м. Один из них - выполняет роль руководителя. На этого руководителя поступают задачи по 1С от пользователей.

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

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

Обычно все через ( | ) делается. Без ТЗ.

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

Все зависит от уровня компетенции каждого в разных областаях- кодинг постановка общение понимание....

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

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

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

(0) автор, ты программист, или тот третий (который - хочу, сделаю,  а хочу нет)? :)

делай через жеппу. так все делают

(7) типа печатных форм без ТЗ  - эх мне бы такие печатные формы, а то скажут а нам в отчете нужна такая информация и начинается...

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

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

(0)

1. пример задач
2. ТЗ по ГОСТу

?

Всё зависит от конкретной ситуации, задач на входе, их объема, квалификации исполнителей, квалификации руководителя, типа потока задач, наличия аналитиков и тестера, критичности системы итп итд

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

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

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

а вообще щас настолько дохера различных методологий и советов по организации работы программистов (Скрам, канбан, XP, TOC, Lean, 6sigma, водопад, классические через ж0пу и как получится, sweebok, itil итп) что иногда проще свое придумать

(0) Очень ОЧЕНЬ советую прочитать - "Как пасти котов", читается на одном дыхании буквально за одну ночь. Про то как пасти котов(программистов)

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

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

(18) в шею таких руководителей

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

ИМХО Руководитель должен знать автоматизацию организации от А до Я :) Иначе присоединяюсь к (19)

(19) руководитель должен руководить, а не уметь делать все то, что умеет команда, только лучше

(21) зачем прогу кривой постановщик ?

(16) Обязательно прочитаю, спасибо!
(18) Это уже край. Я постепенно прихожу к вывожду что руководитель должен быть максимально компетентен как проектировщик и иметь полное представление о работе 1С в компании. Пусть даже в ущерб техническому знанию языка 1С.

(21) если руководитель - чей-то ставленник (который может вообще ничего не знать) - то да, а в нормальном случае - нет

(22) постановщик, аналитик и руководитель - разные вещи, но руководитель должен понимать, что делают его подчиненные, и как это проверить, но не должен уметь сделать это полностью сам

(23) Хотя знание руководителем механизвом платформы, конечно, необходимо, иначе невозможно нормально составлять ТЗ.

+(25) еще есть архитектор и тех.лид и тим. лид

(0) Руководитель получает первичные данные о поставленной задачи. Распределять задачи с ссылкой на того кто поставил.
Программист в случае необходимости общается с тем кто поставил задачу.
ТЗ формируется на основании полученных данных от Руководителя и уточненных данных от Постановщика задачи.

Вспоминается картинка ... Работает Вася Пупкин, а рядом куча руководителей стоит и ничего не делает :)

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

(0) Должностная инструкция.doc
по опыту:
- если помогает - не справляется со своими задачами
- - если не помогает - "жлоб какой-то"
:))

(12)  Неужели такое где-то есть? Мечтаю в таком месте работать..

(28) Я пришел к выводу что первичных данных по сложной задае руководителю не достаточно, т.к. программист, пообщавшись с пользователем, в такие дебри улезут, что потом сами не вылезут, и руководитель им не поможет... остается (1)
Речь, повторюсь, о сложной задаче.
Пример для (13):
Перепиленная вдоль и поперек УПП для комплексного учета по холдингу. Работают с ней финанситы. Хотят разработать сводный баланс для отчетов руководству.

(30) безусловно. Но мы живем в реальном мире :)

Как думает пользователь:

1. Требуется что-то добавить
2. Звонок программистам по телефону или приход лично и рассказ (возможно с бумажными зарисовками) "мне нужна кнопка, которая возьмет и начислит по этому физлицу.."
3. ???
4. Прошла неделя
5. Profit!

Если п.5 не случился (что часто бывает) - возвращаемся в п.2, но только задача переформулируется "Я же говорил(а), что нужна таблица, в которой я нажму кнопку! А почему я не могу выбрать эту строчку? Почему тут написано "ААА", это же полный бред,  должно быть "БББ". Не работает ваша программа"

6. (n итераций)
... Profit!

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

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

А нах такой руководитель, который только задачи распределяет? Тогда уж лучше красивую девочку с 3 размером за 20к взять ))

(37) хорошенькой можно и по-более платить =)

(0) исключить программера-руководителя прелагать?

(38) зачем?  Им чем меньше платишь, тем лучше работают ))

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

(40) тогда лучше на минималку + премия

(41) а вдруг это уже реализовано в конфигурации и ты будешь изобретать велосипед ?
а вот если бы учёл тонкости - не было бы изобретение велосипеда

+(34)
А правильнее так:
1. Требуется что-то добавить
2. Звонок программистам по телефону или приход лично и рассказ (возможно с бумажными зарисовками)
"мне нужна кнопка, которая возьмет и начислит по этому физлицу..".
- пожалуйста, опишите требование в письме.
- ну опиши сам, тут же понятно, напиши "Нужно кнопку которая начислит с 1 по 31."
- так, эта кнопка наверное в документе ААА на закладке БББ должна быть?
- ну да, там
- ладно. я написал, поставьте согласие"
- (пользователь ставит каким-то образом согласие)

3. ???
4. Прошла неделя

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


В итоге через несколько месяцев все наладится

Для "нерядовых" пользователей данная схема может заменятся на схему из (34) по требованию данных пользователей.

ВЫВОД: если при такой схеме ты не франч - все равно придется переделывать все нахаляву (или ругаться) :)

(0) Про Ситуационное руководство, уровни зрелости и стили руководства почитай.

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

(46) делать надо так, чтобы потом не возвращаться к этому вопросу

(46) например?

(45) Почитаю, спасибо!

+ Спасибо всем, я получил ответ на свой вопрос, теперь пофлудим, авось еще что интересное кроме девочки с большими титьками появится :)

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

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

(47) не возвращаться к этому вопросу ? сделать качественно

еси чо, я знаю про принцип "Повышение качества системы снижает расходы на ее разработку"

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

фраза "ранняя оптимизация - корень всех зол" тож сюда подходит

+(52) там знак "не равно" должен быть вместо ?

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

(54) дык если это поменять стоит 10 минут где то в будущем, а сделать правильно - от 2х часов (я не про случай, когда в конфе это уже все есть, просто "Ответственные лица" не заполнили), то стоит ли оно того, чтоб делать правильно?

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

(55) А я как раз про случай, когда не юзают типовое.

Читать:
Методология разработки (RAD, RUP) - Для организации работ.

Учить:
UML - для моделирования системы.

Ответы придут сами собой.

(32) в чистом виде пока не видел. Собираю плюсы из различных мест работы.

(35) все правильно сказал

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

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

(+62) И уметь принимать нужные решения.

Согласен с (15).
Передать задачу. Спросить как планирует решать и примерные сроки.
Если путь решения не вызывает вопросов - гуд.
Если сроки (считай стоимость разработки) устраивает - гуд.
Иначе чесать репу и искать другие пути.

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

(58)  ЧО дает УМЛ как средство описания 1с?

ОТвет ничего

(+63) нужные и правильные решения в условиях неопределенности )))

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

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

(7) " легкие задачи типа печатных форм без ТЗ"
Главное, чтобы для новой колонки в печ форме не пришлось регистры в конфу добавлять...

(66) Нужно уметь презентовать решения как правильные, и признавать что были и неправильные

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

(70) Разуй глаза, твой код кто-нить инспектирует?

ЗЫ  и не будут ибо по стоимости это будет в 2 раза дороже минимум

(71) Достаточно пару раз посмотреть на код.

(72) после этого ты будешь постоянно туда смотреть, я не работаю с теми людьми, в чьем профессионализме я не уверен ;-)

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

Опять же проги очень плохо работают в плохом настроении- а следовательно он заберет еще времени на обдумывании следующей задачи ;-)

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

(75) ТОгда вы путаете понятие программиста и кодера, вот кодер не включает моск, программист -обязан ;-)

(74) при введении аудитов у нас уровень 1-3х летних программистов сильно подскочил.

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

(78) МП может присутствовать на аудите и выступать модератором, ему весьма полезно знать кто как пишет и разбирается в коде. В зависимости от вида инспекции и целей инспектировать может тех.лид/архитектор/ведущий программист, программисты такого же уровня или программисты уровнем ниже. Частенько МП по знаниям и опыту равен тех.лиду (или является им).

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

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

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

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

(81) у меня подозрение, что присутствует личный негативный опыт в этом направлении =)

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

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

Ну а ставить на роль МП нужно не самого сильного разработчика, а самого коммуникабельного с лидерскими способностями. Вот есть забавный кейс на тему кого ставить: http://www.happy-pm.com/blog/?p=2805

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

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

(50) Да здравствует рабство? Как работать в этот период? на xx% от оклада, в данном случае выхлоп только на 50%?

(81) Правильно. Кому нужен человек, глядя на которого понимаешь свою никчёмность?

(65) Ну да UML вообще придумали дураки.
И весь мир  им пользуется - тоже дураки.

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

Потому и все смеются на 1С программистами, книжку прочитал по синтаксису - ВСЕ, программист.

Смешно.

(88) Зачем ЮМЛ для (0)? Ставить задачу программисту в диаграммах последовательности?

(88) в 1с как правило не настолько большие проекты + часто не с нуля, чтобы пользоваться УМЛ. + прибавить к этому чудо-заказчиков, у которых постоянно здесь играем - здесь не играем - здесь я селедку ел, и польза от умл становится ну очень умозрительна. + потоки, классы - от этого всего 1с несколько далековата

Отвечаю:
(89)
Программист моделирует то, что он собирается делать.
Начальник проверяет и принимает решение о выполнении или доработке.
Это:
1) Позволит начальнику контролировать выполняемую работу (правильность решений).
2) Согласовать с заказчиком (в данном случае внутренним) результат.
3) В случае вопросов программиста к начальнику объяснятся не "на пальцах", а на конкретных структурах.

Ну и побочные следствия:
1) Документировать свою работу.
2) Приучать программистов сначала думать, а потом программировать.

(90)

Даже в небольших проектах есть итерации, которые нужно делать:
1) Спроектировать требования к системе.
2) Согласовать с заказчиком.
3) Продумать структуру и взаимодействие объектов.

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

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

(91) Нафига моделировать формочки и отчетики, где половина работы (если не больше) это програмиирование интерфейсных элементов. УМЛ для структуры данных, для бизнес-процессов, вы их что каждый день переписываете?
Кстати если очень хорошо разбираешься в проектировании систем, то должен знать что переписывание и перепроектировании - это просто неотъемлемая часть процесса, так что этого не избежать. Сделал, понял что не так, и начал проектировать заново. Этому даже в институте учат ;)

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