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

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

ИМХО все зависит от уровня подробности ТЗ
и если тестировать и внедрять будут другие люди, то может и не нужно

Вот смотри, у тебя в теме Doomer Mashinist Мизантроп Wobland  pumbaEO andrewks - что ты хочешь услышать от "не кодеров" ?

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

Постановщик задачи описывает все поведение доработки. Он описывает все метаданные участвующие в доработке.

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

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

(4) имхо, грань очень тонкая.
(3) при такой постановке: кодер - это печатная машинка.

(4) в твоей схеме узкое место это консультант, умеющий ставить задачу на уровне метаданных

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

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

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

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

Архитектуру конфы должен знать Архитектор
Это не консультант, а в общем руководитель команды разработчиков т.е. это по сути PM
Он в принципе может не программировать
Его задача работать с product owner т.е. с заказчиком для разработки нового функционала и с консультантами для устранения багов и рефакторинга

(11) опередил :-)

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

(14) http://bit.ly/Nn4az6

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

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

(16) Значит разработчик хреново знает конфу, вот и все

Где голосовалка?! Не знаешь конфигурации - начнешь изобретать велосипед. Если брать последние конфигурации на УФ, то надо изучать БСП.

....а как же не знать, если ты в неё собираешься интегрироваться?:)))
На мой взгляд, обязательно.

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

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

Если бы это ТЗ писал консультант, естественно он бы описал необходимость создания нового реквизита документа. Что в будущем удорожало бы содержание конфигурации, т.к. её нужно периодически обновлять.

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

(21) где ты таких кодеров видил

(19)реалбный кодер БСП юзать не будет, это ниже его достоинства, он лучше понарисует своих говноподелок и будет орать как он крут.

(21) где ты таких консультантов видел, которые скажут в реквизит документа пихать, а не в Свойства?

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

(21) "ТЗ нужно писывать функционал с точки зрения пользователя"
А кодеру...найти такое решение, которое позволит отказаться от доработки конфигурации"

Это как раз задача консультанта, а не кодера.

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

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

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

(23) - (26)  Да, тут не хватает архитектора ;)
кодер - архитектор - консультант.
Если эти функции выполняют два человека, то получается например кодер-архитектор + консультант-аналитик.
И ТЗ imho должно быть два и более - одно для заказчика с описанием на уровне пользователя или на уровне общего функционала и остальные для кодера(ов).

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

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

(29)Соглашусь!
Для реализации пожеланий ГБ.Пришлось сохранить Книгу покупок во внешний отчет и доработать так, чтобы по с/ф на полученные авансы выводилась не наша Организация, а Контрагент.
Только потом обнаружил в настройках флаг "Выводить покупателей по с/ф на полученные авансы"

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

(0) нужно ли Стошнику знать машины? Нужно ли знать продавцу о своих товарах? Нужно ли доктору знание анатомии человека? нужно ли знать....

(32) На том же СТО. Есть мастер приемщик который общается с клиентом (по сути тоже консультант в терминал 1С) и механик который выполняет все работы (тот же кодер). Нужно ли мастеру приемщику разбираться во внутренностях автомобиля, болячках конкретных моделей, принципах ремонта? По моему нужно. А у механика все работы описаны по операциям. Сначала вон ту гайгу потому вот эту и т.д. Причем даже фильмы производители специальные создают для обучения механиков.

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

кодеру который работает самостоятельно - в обязательном порядке. Кодеру, который работает по ТЗ - крайне желательно. Ибо знание метаданных типовой конфиги - еще не залог успеха. надо знать методики применения типовых конфигураций, чтобы понимать ЧТО писать. или ТЗ должно быть настолько подробное шо пипец...
.
именно поэтому у меня не взлетают отношения с фрилансом... пока напишешь такое ТЗ , чтобы получитьТО ЧТО НАДО - дешевле самому написать, ибо написание внятного ТЗ для КОДЕРА - занимает времени ну как минимум 50% от времени самого кодинга.

Пожалуйста объясните мне круг обязанностей Архитектора и как он взаимодействует с прогом и консультантом. Не нашел я понятного для себя объяснения.

(4) тебе нужен разработчик а не кодер в таком случае иначе конфа через какое-то время станет очень "интересной".

(35) в свое время, писал ТЗ, "как себе" - такой минимум, чтобы было понятно, но без лишних деталей. Нашел фрилансеров с похожим отношением к ТЗ и добавил итерации. Успешно сотрудничаю со многими более 7 лет (10, но 7 из которых уже с RMS).

(0) знания типовых увеличивают эффективность работы.

(38) угумс, вот весь вопрос чтобы таких людей найти, которые при таком ТЗ - задают только правильные вопросы... ;-) а наработать таких  людей - это как везде - 100 человек пройшло, 5 - внятных.

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

Еще раз прошу рассказать про Архитектора.

(40) и обратно пропорционально: на 100 набирающих работодателей 5 вменяемых)))))

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

я-бы пошел от другого вопроса:

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

по этому мы имеем выбор студент или профи, каждый выбирает для себя :)

(45) я такой)))) вот уже пол года как без работы, никуда не берут)))) 12лет стажу

(44) Но если это БП подозреваю, что такой финт ушами не прокатит, по крайней мере в точно ЗуП нужно понимать как, что работает, чтобы корректно работал определенный механизм расчета.

(46) куча сертификатов наверно?

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

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

(49) за 12 то лет можно было разжиться, не одним

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

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

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

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

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

(0) Естественно. И даже лучше

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

Надо знать конфигурацию на уровне методологии, но тогда не получится "на все руки мастерат", как это любят наши франчи

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

(60)+ уволили правда за то что из сапа не смог в зуп данные подгрузить)))

(61) + времени не хватило

(0)
Знание типовой нужно для более эффективной работы, при которой не нужны будут столь подробные ТЗ.

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

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

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

(64)[чисто типовые не нуждаются в доработке,]
видимо с УПП ты не знаком =)

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

(0) не нужно
(1) а что, бухи знают " общие модули, методы существующих объектов"?

(63) хотя ошибаюсь, если в большой команде работаешь то тут тз в любом случае нужно

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

(22) а не надо кодеров за 100 руб в час нанимать. Нормальных ищи.

(70) ничего криминального нет "не пользоваться технологиями внешних печатных форм".

(68)
ТЗ всегда нужно, вопрос в уровне детализации ТЗ.

(0) А вобще не нужно кодеру типовые знать. Ему и ТЗ напишут и тестировщиками потом его творение будут гонять. И будет он писать и переписывать. Цена этому кодеру 50рэ в час.

(0) ИМХО, желательно, но не обязательно. Хороший кодер при создании кода постарается по максимуму использовать имеющиеся процедуры и функции (уровень пользователя тут уже не канает). Плохой кодер будет кодить все подряд (уровень печатной машинки).  Так что, вопрос поставлен не совсем корректно.

(42) Распределение обязаностей по версии/опыту microsoft можно прочитать в этой книге "Microsoft Corporation. Принципы проектирования и разработки программного обеспечения.". В разделе "Роли членов группы в модели процесса разработки".
На память плохо помню, давно читал.

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

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

"Тестер аналитик"
это как мечта о коммунизме ))))
но в нашем случае это не оправдано.

Так про архитектора никто ничего не сказал.

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

(80)[После внедрения новые задачки возникающие у клиента достаточно мелкие. Тут то как раз вопрос как разделить обязанности и сколько человек должно участвовать в процессе.]
один
поскольку ему придётся совмещать все проектные функции
и поскольку писать ТЗ на мелкие хотелки бессмысленно, как по сути, так и по срокам

(0) конечно нет
Чем меньше кодир знает типовых - тем больше я денег заработаю....

(82) а ты разве кодер?

Кодер — программист, специализирующийся на кодировании — написании исходного кода по заданным спецификациям.

wiki:Кодер

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

Насчет тестера согласен. Хотя нужда в таком специалисте существует всегда.

(84)
Мы про реальность говорим, а не про жизнь на Марсе) к счастью

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

(79)
аналитик тире архитектор
отдельно РП, аналитика, и архитектора в чистом виде в 1С за весь свой послужной список не встречал).

(86)  + а тестеров вообще по моему истребили как класс).

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

(87) их вроде и не было никогда как класс, точнее - не знаю где их готовят

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

Другой вариант - заказчик, постановщик задач.

А вот для выполнения функций тестора кем-то другим из упомянутых требуется наличие подробного описания рабочей области. До чего руки не доходят. :(

Обязательно. Это дает знание о том "как надо, и как не надо". ИМХО

(91) не согласен. для этого есть постановщик задачи. Кодер - это (83)

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