Гонки типа ралли «Париж-Дакар» — отличный пример.
Ресурсов одного человека уже не хватает. Нужно минимум два и такая единица уже называется «экипаж».
Как минимум определяются 2 роли: штурман и пилот.
- Штурман — тот кто берет на себя абстракцию, он видит путь от А до Я, смотрит на карту и делает стенаграмму (берет на себя функции коммуникации с внешним миром)
- Пилот — тот кто берет на себя конкретизацию, он видит дорогу и движет экипаж. Его внимание максимально сконцентрировано на конкретном моменте.
Надо ли говорить что 1+1 это не всегда 2. Часто это меньше 2-х и редко это больше чем 2. Для этого оба человека должны дополнять друг друга и доверять друг другу. Если облажается один — проиграют оба.
Моя практика показала, что в разработке такие экипажи также эффективны:
- Один берет на себя роль штурмана, ставит задачу и ведет ТЗ, общается с внешним миром (пользователи, клиенты …). Его внимание абстрагированно. Он не сможет сесть за разработку, даже если очень захочет. Ресурса внимания не хватит, его начнут дергать и отвлекать все те связи, которые он завел на себя.
- Второй разрабатывает. Он пилот. Он сконцентрирован на текущей задаче. Того что будет через два поворота он не знает. Это забота штурмана. Он отключен от всех связей, кроме связи со штурманом. Он слушает его и только его.
Тут также важен фактор доверия.
Штурман должен доверять пилоту и быть в нем уверенным. Не важно что тот творит и какие пируэты исполняет. Нельзя вмешиваться и отвлекать его. Выдавать информацию только дозами.
Пилот должен доверять штурману. Штурман подскажет куда свернуть и через сколько. Какой следующий шаг. Но сейчас есть этот шаг и нужно быть сконцентрированным именно на нем.
Смена роли допустима, но как правило в следующей гонке. В рамках этой гонки — каждый действует в рамках своей роли.
Почему в ралли не участвуют одиночки? Потому что бесполезно. Ты не сможешь прогнозировать путь (абстрагироваться) и тут же рулить отслеживая ситуацию на дороге (конкретизация).
Художнику, когда он рисует пейзаж, надо спуститься в долину, чтобы охватить взглядом холмы и горы, и подняться в гору, чтобы охватить взглядом долину
— Государь, Н. Макиавелли
Related Posts
Восстановление последовательности документов при закрытии месяца в Бухгалтерия 3.0 не завершается
Заполнение табличных частей
Формирование сводных актов выполненных работ
Ввод поступления в переработку на основании передачи сырья (между организациями)- Конспект по установке сервера 1С на linux
Получение имени компьютера и его IP локально и в терминале
Анатолий, к сожалению рекомендуемый Вами подход не соблюдается в некоторых компаниях, в особенности у франчей. У франчей ты должен быть и аналитик и кодер и консультант, и их не инетресует быстродействие выполнения, ибо они уже получили бабло за проект от заказчика и у них одна цель- слить эту задачу на кого то другого.
(1) Manticor, согласен. Это редкая практика. Но так уж получается, что у нас в стране мало где практикуются эффективные методики.
Более того, внедрить тот же ИСО 20000 на мой взгляд много проще чем такие вот ролевые практики. И то редкость.
А вот переход на ролевую работу, да еще и отбор эффективных экипажей — это единичные случаи.
Много проще работу работать, да зарплату получать, с премией за выслугу лет.
(2) в уважающих себя и достаточно солидных компаниях(не франч) все эти ролевые методы уже даво применяются.
(3) Приведите пример, пжл. Не критики ради прошу. Интересно, кто эти фирмы.
А насчет статьи — коротко, и со вкусом. Образно. Многим, наверное, тоже приходило в голову подобное. Хорошо, что кто-то зафиксировал идею.
наверное, ключ сабжа — это:
1ска сама по себе инструмент для быстрого достижения
кодить здесь, если только речь не идет о создании полноценной конфы с нуля, совсем ничего
т.е. мысль автора, может быть, верна для не-1с-инструментов
а в реалиях 1с получается проект типа беловского: есть верткий 1с-менеджер, и есть голодные кодеры за тарелку супа
(ничего личного, по этой схеме работают практически все франчайзи, не только Белов)
(4) tango, по ходу — УПП должны знать оба
(6) WanGoff, Ланит. Cлышали о такой?
(5) tango, к примеру Вам дадут задание — а оптимизируй ка мне выгрузку и формирование регламентированной отчетности. Как, каким образом, что именно не устраивает, какой код поменять(толи функция долго выполнятется, то ли запользован не тот тип данных)- все повешено на одного программиста-консультанта. А вообще взять ту же УПП — практически во всех проектах по внедрению нужно прелопачивать код процентов минимум на 40 а то и все 60. Это из практики).
Умолчу о тарелке с супом(…
(8) Manticor, хороший пример
основное время на этой задаче — расковырять творчество кодеров флагмана и проникнуться глубиной креатива его же методистов
если основа сделана, то кодирование там может свестись вовсе к паре строчек
если «штурман» понял, что это за строчки, ему быстрее написать их самому, чем объяснить кодеру
если не понял — зачем он вообще?
более интересно было бы разобрать пример с заменой ЗУПовских запросов на что-нибудь более вменяемое. Но это уже будет сопоставимо с разработкой полноценной конфы
(8) Честно говоря, не очень много. Хорошая контора? Как она ведет проекты? Судя по всему, они внедряют Бухгалтерию и Консолидацию в основном. Своих продуктов нет.
И все же насчет подхода я выступлю в защиту. Ваши примеры, друзья, верные, они легко разбивают позицию автора. Однако, мне видится, что такой подход применим при более-менее комплексном внедрении, когда есть архитектор и более-менее понятно, как будет развиваться разработка.
(10) WanGoff,
вопрос остается
УПП: должны ли видеть место нового функционала среди типовых шняг оба — и кодер, и архитектор,
или кодер может спокойно себе кодировать хотелки юзеров, транслированные к нему архитектором?
прикол еще в чем:
кто будет платить, если код придется переделывать?
(11) tango, по-хорошему, нет. Не оба. Архитектор должен корректно встраивать функционал. А кодер — он должен реализовывать. Как раз реализуется описанные в статье механизмы — архитектор видит картину в целом, а кодер — текущую ситуацию (например, будет ли код мешать коду, реализующему другой функционал)
короче, резюме
роли — это роли
а вот будут ли эти роли разнесены по разным учаснегам — вопрос масштаба проекта
архитектор на большом проекте не наблюдатель за интеграцией нового функционала в типовуху («будет ли код мешать коду»), а координатор между своими же кодерами. но тогда столь красивая аналогия, предложенная ТС, уже не работает
штурман шумахера михаеля не штурман шумахера ральфа
Грамотно написано.
(4) прошу обратить внимание на строчку «Как минимум определяются 2 роли».
Архитектор там 🙂
Если это единичный заезд, то штурман может быть архитектором, а может быть и пилот. Кто-то берет эту роль на себя. В малых системах ее ценность минимальна.
Но если это лишь заезд в рамках какой-то серии? Экипаж — это лишь часть всей команды. За их спиной трудится иногда еще большая группа. От главного тренера, который их инструктирует, до тети Маши, которая им вкусные пирожки готовит. Да и экипажей в таком случае может быть много.
В таком случае архитектор, этот тот кто писал им ТЗ. Или принимал участие в написании ТЗ.
И более того, архитектор во время гонки никуда не испаряется. Он находится на прямой связи со штурманом.
Но даже архитектор понимает, что общаться надо со штурманом, а не с пилотом. Пилота трогать — в момент гонки. Можно не слабо так гонку просрать )
Неудачная аналогия. Если архитектор и кодер работают одновременно, то это не Париж-Дакар, это Париж-Куда_приедем_туда_приедем. В этом случае штурман не нужен, т.к. цель максимально быстро приехать из точки А в точку Б не стоит. Единственная цель в этом случае — это показательно с дымом из-под колес и ревом мотора отбить бабки спонсора.
Если же работа выполняется последовательно(как и должно быть), то какой смысл кормить 2 человек? 2 пилота, самостоятельно подготовивших маршрут заранее, пройдут его за то же время, что и один экипаж штурман+пилот дважды.
И не надо про мифических кодеров, не разбирающих в азах построений бизнес-процессов. Такой лапоть ничего вам не накодит, или время на разжевывание ему ТЗ будет непомерно большим.
(17) mymyka,
отчего же. 4 + уже есть
(19)Ну дак и что вам накодит такой
? или сколько вы ему будете разжевывать, что вы от него хотите? Как он будет действовать, если наткнется в процессе написания кода на явное противоречие(например, недостаточности данных в установленных источниках), до какого уровня детализации будет разложена проектная документация? Если он не может
проектную документацию ему придется писать на уровне едва ли не самих процедур/функций. На разработку такой проектной документации вне системы разработки архитектор потратит уйму времени, за которую мог бы сам реализовать в коде задание, как минимум, дважды.
просто /рукалицо, no comments. Если вы вынуждены руководить людьми, опыт которых заключается в развозе дисков ИТС длиной в 3 месяца, остается только посочувствовать и серьезно обсудить с начальством соотношение з/п программистов и ожидаемого от них выхлопа.
З.Ы. Связка ИТ-руководитель(70т.р.)+слабый прог(30тр) ВСЕГДА будет слабее, нежели 2 средних прога(50т.р.+50т.р.).
ну да картинка складывается примерно такая:
есть поток студентов, слышавших, что 1с это ацтой, но денег на пиво дают
этих человеков с конторах типа Ланит называют 1с-программистами
понятно, что с этими человеками надо что-то делать, и так рождается сабж
(20)(21)
Господа ) я не 1с-ник.
Просто умею создавать информационные системы. Мне не важно на каком программном продукте они будут вертеться. Лижбы приложение было не совсем убитое и этого мне достаточно чтобы запустить систему и чтобы она начала приносить пользу предприятию.
Но ввиду такой специфики мне часто достаются проекты на самых разных платформах и стеках технологий. Соответственно работаю с разными масштабами систем (от 10 до 1000 пользователей) и типами программистов (от php до 1с).
И если мы говорим о процессах, соответственно о неких прикладных информационных системах, где вопрос внедрения упирается в общение с пользователями и сотрудниками соответствующих отделов, везде замечал такой вот подход. Он как то сам образуется. И беда там где его нет. Где есть супер герой, который все сам мастерит и с его уходом можно закрывать предприятие. Или там где забитые программисты уже не первый год ничего толком наладить не могут.
Везде где отдел ИТ показывал более или менее нормальные результаты, были замечены такие вот экипажи.
То что вы их не встречали — бывает такое. Вот только не надо тут додумывать факты, которые не соответствуют реальности и существуют только в ваших головах.
(22)
с этого надо было начинать
(20)
>> З.Ы. Связка ИТ-руководитель(70т.р.)+слабый прог(30тр) ВСЕГДА будет слабее, нежели 2 средних прога(50т.р.+50т.р.).
Это заблуждение. В моей практике был случай, 2-х похожих проектов, где связка «руководитель»+»молодой прог» обогнала связку «10 средних и сильных программистов». Затем расклад сил чуть поменялся, но не сильно.
А когда подвели итоги за год то получили:
1. В одном случае затраты по проекту составили порядка 3 млн руб и охват порядка 20 процессов
2. Во втором случае затраты по проекту составили порядка 7 млн руб и охват порядка 3 процессов
Разница в том, что в п.1 применялся принцип экипажа. А во втором — каждый сам по себе, во главе с самым умным.
Платформы были одинаковы и среда работы тоже. Разница только в организации работы специалистов.
Когда подняли статистику по работе, то выяснили что в случае с п.1, 80% это были улучшения и 20% ошибки, а в случае с п.2, вся эта толпа в 80% задач закрывала ошибки которые сами же наделали и только 20% их задач были связаны с улучшениями.
Но чтобы это увидеть, нужно в отделе ИТ внедрить ИСО 20000. А много ли где оно есть?
Это все позволило мне сделать выводы, с которыми я поделился в этой статье.
Я не прошу с ней соглашаться, но прошу не высасывать фантазии из своей головы и не пытаться их выдать за факты.
(24)
🙂
всё верно и красиво. совпадает с моим мнением по данному вопросу. Всё кроме одного. Наряду с автомобилями и грузовиками в ралли «Париж-Дакар» принимают участие мотоциклы. А это удел одиночек….
(24)
это лишь свидетельствует о квалификации «средних и сильных программистов». Прог, который 80% времени правит свои ошибки это вчерашний студент, работающий на коленке без ТЗ. Назвать такого «средним» и уж тем более «сильным» язык не поворачивается.
Не надо думать, что только «руководитель» способен организовать работу. И уж тем более пытаться нелепыми теориями оправдать бесполезность такого «руководящего» звена в связке с работником, способным к самоорганизации.
ИТ-директор+2(3)средних прогов+разделение по направлениям = успех
ИТ-директор + связка(Начальник ИТ+слабый прог) = баблопильство и вечные отговорки(типичная схема в Роиссянской действительности)
Если ваш прог не может работать сам, увольте его к чертям, дайте нормальную зарплату(а не 120% оклада уборщицы), и наймите специалиста.
(27) mymyka, тут еще вопрос, а нужен ли им такой прог? несовпадение личных целей и декларированных — встречается не только на проектах.
для меня в свое время было открытием, что на собеседованиях не следует показывать себя
слишком умным
(26) Вот это я упустил 🙂 Да, статья не отрицает то что существуют задачи которые можно решать в одиночку. Более того, таких задач много больше. Это основной поток.
Ровно как существуют заезды целыми группами.
Она лишь говорит о том что существуют ситуации, когда задачу эффективней решить экипажем из 2-х человек.
(28)В целой куче организаций я видел подобную ситуацию. Есть начальник ит, который последний раз программировал в далекие 90-ые. С з/п, превышающей среднюю по отрасли раза в 1.5. И бесконечная череда сменяющих друг друга вчерашних студентов с мизерной зарплатой, мизерном опытом и таким же мизерным желанием работать. Про плачевное состояние автоматизации на таких предприятиях можно и не говорить, не смотря на солидный ФОТ отдела автоматизации.
Руководитель не должен делать работу прога. Не должен писать ТЗ. Не должен вникать в реализацию проектов. Он должен предоставлять ему административный ресурс, мотивировать и помогать организовывать рабочее время.
Наверное нужно преподносить данный подход как хороший способ решения проектных задач для команды исполнителей.
Тогда меньше было бы абстрактных возражений от кодеров-одиночек, работающих без команды, и, как следствие, задающихся вопросом «зачем мне это нужно».
(31)Согласен, при условии, что команда состоит из более чем 2 человек. Тогда это рациональное использование рабочего времени, иначе просто бессмысленная трата денег. Обычная задача про КПД. Потери на уровне взаимодействия между исполнителями превышают выгоды от разделения труда.
Когда это начинает понимать начальник ИТ, он вырастает до ИТ-директора.
(31) anchovy,
хорошая абстракция
(0) К утверждениям и абстракциям Анатолия отношусь очень скептически.
Но дело в том , что взгляд с другой колокольни (т.е. непрограммиста) очень интересен на ИС.
(33) tango, Это предложение как ее избежать и не давать повода к пустословию.
Попробуйте прочитать еще раз.
(35) anchovy, это по-вашему так. а по-моему — чистый флуд
Связка 70+30 как мне кажется эффективнее. Но только теоретически.
Но т.к. профессионализм в 1С оценивается очень субъективно и часто позицию «70» занимает более разговорчивый, а не более соображающий.
Поэтому 50+50 пожалуй для практики правильнее. Работают двое и подтягивают друг друга по возникающим проблемам.
(37) KapasMordorov,
среда для практики своеобразна. настолько, что попытки подтянуть типа MBA-«разговорчивых» мальчиков вызывают лишь кривую усмешку
ОФФ.
Анатолий, в статье ты пытался донести некоторые истины на ассоциативном уровне.
Сразу скажу , в любом профессиональном сообществе объяснения на ассоциативном уровне — очень дурной тон. И вот почему .
Непревзойденным чемпионом по использованию ассоциативного подхода является Христос, ему позволено.
«Для чего притчами говоришь им? Он сказал им в ответ: для того, что вам дано знать тайны Царствия Небесного, а им не дано, ибо кто имеет, тому дано будет и приумножится, а кто не имеет, у того отнимется и то, что имеет» (Мф. 13:10).
Что означает этот ответ сейчас неважно. Важно то , за кого держит большинство слушающих «вещающий ассоциативно».
Огорчу тебя , Анатолий . Ты не Мессия.
Великое искусство абстрагирования и обобщений — тебе не позволено.
Забудь ты «штурманов» и «пилотов» , анализируй конкретные ситуации «РП — исполнитель».
И народ к тебе потянется.
(39) Ish_2, пять баллов
каждой жене по мужу
(34) Спасибо!
Мне не нравится критика. Но я всегда ей рад 🙂
Публикация статей тут, это не попытка показать какой я умный. Это один из методов проверки идеи на прочность.
Чем мне нравится ИС, так это тем что кроме троллей тут бывают и нормальные комментаторы. Которые умеют аргументировать, отличать факты и от фантазий и правильно их подавать.
Идея — это такая штука, что кому то она может просто нравится. Кто-то ее разделяет. Кто-то становится ее противником.
Сама позиция не важна. Важна точка зрения человека и то что он думает. Если то что он думает, подтверждаемо и реально, значит это позволяет корректировать идею.
В данном случае, благодаря комментариям, эта идея уже получила существенные дополнения и корректировки.
И это не в первый раз.
Всем спасибо! 🙂
Дела … ни о чем ни про что …
Водитель и штурман, Чип и Дейл, Банни и Клайд, Ильич и Крупская, 50/50 или 70/30 … Чем больше ФОТ работникам тем меньше остается доходности… Всегда кто-то должен смотреть за дисциплиной, сроками, качеством — в случае начальник-подчиненный — есть четкая иерархия и система работает лучше, чем 10 средних программистов — которые в курилке сходятся во мнении, что заказчик идиот и что форсировать выполнение конкретной задачи глупо.
(39) +1
Вообще аналогии — простой и эффективный способ убеждения (кого угодно в чём угодно), об этом в любой книжке про «эффективные продажи» написано. Однажды на прошлой работе попробовал использовать этот приём чисто для интереса, результат превзошёл ожидания. Теперь с большим недоверием стараюсь относится к таким «доводам».
(41) один из первых признаков никчемности тезиса — охотка, с которой автор прибегает к «защите от троллей»
(41) ты достиг своей цели, молодец.
Мир этому дому!
Это принцип «парного программирования», используемый в экстремальном программировании. Вот как описаны его преимущества в книге :
«Вот пока несколько выводов после применения парного программирования:
• Парное программирование действительно улучшает качество кода.
• Парное программирование действительно увеличивает сосредоточенность команды (например,
когда напарник говорит: “Слушай, а эта штуковина точно нужна для этого спринта?”)
• Удивительно, но многие разработчики, которые выступают против парного программирования, на
самом деле не практиковали его, однако раз попробовав – быстро понимают все преимущества.
• Парное программирование выматывает, так что не стоит заниматься им целый день.
• Частая смена пар даёт хороший результат.
• Парное программирование действительно способствует распространению знаний внутри
команды, заметно ускоряя этот процесс.
• Некоторые люди чувствуют себя некомфортно, работая в парах. Не стоит избавляться от хорошего
программиста, только потому, что ему не нравится парное программирование.
• Ревью кода – хорошая альтернатива парному программированию.
• У “штурмана” (человека, который не пишет код) должен также быть свой компьютер, но не для
разработки, а для выполнения мелких задач, когда это необходимо – просмотра документации,
если “водитель” (человек, который пишет код) запнулся и так далее.
• Не навязывайте парное программирование людям. Вдохновите их, дайте необходимые
инструменты и позвольте самим дойти до этого.»
Кстати, книга очень интересная — это опыт удачной команды по организации создани ПО.
Спасибо автору за интересную тему! Ваше виденье очень сильно перекликается с идеями Брукса опубликованными еще в 75 году. (см. Хирургические группы)
В 1С я пришел из Oracle, где цикл разработки программных продуктов на порядок дольше и команды больше.
Так вот, у нас команда на старте была такая:
Пара ИТ-Директор+его зам.
И три тройки. Закончилось ИТ отделом в 101 человек. Закончилось плохо, так как парочка ИТ директор+его зам, развалилась и развалила всю команду. А вообще деление на пары и тройки, я считаю очень продуктивной. Пары стабильней и встречаются чаще. Стабильные тройки всегда имеют внутренний конфликт, распадаются как только нарушается баланс в отношениях.
По моему опыту — пары ОЧЕНЬ ЭФФЕКТИВНЫ.
Но распределение ролей может быть различным:
Штурман+Пилот — в «сложных» с точки зрения отношений с заказчиком проектах
Первый пилот+Второй пилот — в больших проектах.
Консультат+программист — в разработке с нуля.
Пары очень эффективны и в бизнесе. Очень сильная пара получается, когда
директор — эмоциональный экстравер с мощной интуицией и харизмой, работающий во внешней среде,
и его заместитель — технарь интроверт с аналитическим мышлением нацеленный во внутрь компании.
Первый хорошо работает в условиях неопределенности, второй эффективно использует наличные ресурсы.
А самое интересное заключается в том, что в природе зачастую жизнь продолжается тоже благодаря парам.
PS Мне кажется, что благодаря развитому инструментарию 1С — пара из первого и второго пилота наиболее жизнестойка.
(46) да, одна из причин которая натолкнула меня на эту идею, это как раз после того как я узнал что существует парное программирование. Также услышал что мнение на этот счет разное.
Меня можно назвать программистом, но с большой натяжкой. Я знаю много языков. Около 10. Могу на них писать.
Причем у меня врожденное и обостренное чувство ООП. Плохо перевариваю все что не подходит под это.
При том что ставил задачи в этом стиле уже более 5 лет. Сам первый ООП код написал лишь пару месяце в назад.
И вот понял что почти все проекты, с которыми встречался в последнее время, были в стиле 1+1. Но это не было так что оба кодили. Это всегда было так что один кодил, а второй искал недостающую информацию и прокладывал дорогу к цели.
И уже давно не помню проекта, где был бы один программист, который чего то там делал. Цукерберг не в счет. Доржи тоже.
И конкретно мои проекты в последнее время проходят в этой паре. Где я выполняю роль штурмана. Всячески убирая все отвлекающие факторы от пилота. Как только кто то добирается до пилота и начинает его тюкать, начинаются проблемы. Даже на совещания стараюсь не брать. Если они слишком не по делу. Только на отчеты (если по советски) или демки (если по SCRUM), где нужно показывать результат работы.
Причем у меня врожденное и обостренное чувство ООП. Плохо перевариваю все что не подходит под это.
А ты вообще в курсе, что ООП — это давно уже не самая крутая тема в программировании?
Поговаривают даже, что ООП отжило своё, лет примерно 10 тому назад.
Так что, хвалиться тут особо нечем.
Чувак, дай я угадаю!
Ты трудишься начальником отдела ИТ на каком-нибудь заводе. И у тебя в подчинении есть программист 1С, который под твоим мудрым куроводством что-то там ваяет нетленное (наверно, мега-CRM).
(50) EarlyBird,
А какая самая крутая тема в программировании?
(52) Evgen.Ponomarenko, интернет тебе в помощь, эта информация вроде не засекречена.
(53) EarlyBird,
В данном случае меня интересовало конкретно Ваше мнение. Своё у меня уже давно сформировалось.
Можете привести методики/технологии круче чем ОПП?
(55) EarlyBird,
А нечего стебаться над топикстартером, есть что добавить — скажи по существу. А так получается стеб ради стеба.
А вообще вопрос все равно интересный. ООП не может умереть, это основа структурного программирования, в той или иной степени присутствует во всех направлениях.
И пусть топикстартер нас рассудит 😉
(56) Evgen.Ponomarenko,
Я уж как-нибудь без твоей помощи разберусь, что мне сказать топикстартеру. Ты ему кем приходишься, мамой?
(9) tango,
🙂 посмотрите статью
Интересная статья и более чем интересные комменты. Самое смешное, ИМХО, что очень много копий тут поломато из-за путаницы в терминологии — что разные люди например понимают под словом «программист», и выводы сделанные из этого. Утверждение (30)
мне кажется нуждается в какой то степени расшифровкой, что в данном случае понимать под «программист» и «руководитель». Если программист — тот кто пишет код, то ему не зачем составлять ТЗ — он по нему должен работать, если программист пишет ТЗ и код, то он уже и программист и постановщик задач и много ещё чего, аналогично с руководителем, руководитель руководителю рознь :-).
Про связку штурман-пилот ТС написал правильно, и тут речь не о сытом руководителе и голодном программере, а о команде (экипаже) — суть ИМХО в этом.
По своей практике уже не раз убеждался, что если решать задачу не в одиночку, а вдвоем (или большим количеством) и кодить и общаться с клиентом намного непроизводительней, чем в ситуации когда кодит один (два, три …), а второй занимается постановкой задачи, тестированием и общением с клиентом. Результат получается быстрее и более качественно.
Здравствуйте!
Первое — на мой взгляд, хорошая статья. Можно для себя взять хорошую идею. Пусть она подходит не для каждой задачи — согласен: где-то достаточно одного программера. Но если он начинает буксовать (не успевает, много времени уходит на разговоры с клиентами, с начальством и пр.) — возможно, стоит задуматься о штурмане? Ситуаций бывает множество и встречаются непохожие друг на друга.
И второе — не бросайтесь помидорами 😉 Думаю, подобные статьи существуют для того, чтобы чему-то научиться и взять из публикации лучшее. Или дополнить мысль ТС. Зачем брать (выдумывать) плохое? Плохого вокруг и так достаточно…
(59)Я пытался донести до ТСа, что именно в рамках 1С, написание проектной документации(в простонародье называемой ТэЗэ), не привязанной к среде разработки либо занимает чудовищное количество времени, т.к. оперирует ненативными для 1С понятиями, либо сама проектная документация не исполняет своих функций полного технического описания проекта, и является по сути примитивной пользовательской хотелкой, для написания которой необязательно обладать особыми компетенциями.
Плюс не надо смешивать подход к созданию/модифицированию учетной системы, и написанию корявенького автономного приложения под Андрюшу/Делфи/Сильверлайт/и т.д. Во втором случае достаточно написать общий алгоритм работы, а техническую реализацию можно оставить прогу, т.к. она по сути влияет только на скорость работы и не более того, т.е. система 30+70 работает весьма эффективно.
В случае же учетной системы(не обязательно 1С), для создания алгоритма на обоих этапах разработки необходимо знать объекты дорабатываемой/разрабатываемой конфигурации, существующие подсистемы, учитывать влияние нового функционала на них, сквозные аналитики и т.д. При таком подходе модульная разработка становится практически невозможной и ваш мифический программист-аутист просто не сможет приступить к написанию системы до формирования полной проектной документации, что приведет только к дублировании работы архитектора(описание «на коленке», вне среды разработки, для кодера всех телодвижений в алгоритме) при системе 70+30, или перерасходу ресурсов при системе 70+50.
Если исполнитель умеет планировать свое рабочее время и защищен определенным административным ресурсом от истеричных тетенек. Количество исполнителей на задачу при этом удельную производительность никак не влияет.
(61) mymyka,
— так все ж таки получается что программист не в автономной плавании, а защищен итд, а в качестве того же административного ресурса для защиты выступает «штурман».
— опять спорно — задачи разные, поэтому и количество исполнителей может быть различно, а в случае, когда выполненения задачи надо использовать двоих, то результат будет лучше, если один кодит, другой делает всё остальное. Причем сейчас я говорю о двух специалистах высокой квалификации и ответственность за результат несут оба.
Никто же не предлагает задачи, где достаточно одного грамотного специалиста пилить на двоих.
Пример ситуации, когда подход «штурман — пилот» оправдывается на 200% — «штурман» в полной мере владеет существом поставленной клиентом задачи и методов её решения, но слабо знаком с выбранной конфигурацией, на которой это надо реализовать. Пилот, знающий конфигурацию, потратит на порядок меньше времени на разработку, если задачи будет ставить «штурман», владеющий предметной областью.
(62)
Вот только этим штурманом не обязательно должен быть специалист по автоматизации, это может быть любой человек, имеющий вес и влияние в организации.
так и появляются стандартные монструозные нетленки, допиливаемые годами, счета учета с 5 аналитиками, по которым потом себестоимость считается сутками и прочие стандартные творения «РП».
еще раз повторюсь, эти 2 сотрудника не имеют телепатической связи, им необходимо общаться, так называемому РП необходимо в устной/письменной форме трансформировать хотелки , озвученные пользователями в выбранные способы реализации в учетной системе, ему необходимо заново создать информационное поле для кодера, дабы тот мог определить в каких рамках ему действовать в случае возникновения противоречия. Причем, чем менее квалифицирован кодер, тем больше времени тратит РП на создание этого поля. Это дополнительные ничем необоснованные временные затраты.
Штурману достаточно уметь читать карту, ему не обязательно быть вторым Михаелем Шумахером. Плюс, он может читать не всю карту, а определенный ее участок. В разработке учетной же системы, такой подход не работает. Классическая реализации системы 30+70 это тех.поддержка, но путать ее с предлагаемым 70+30 не стоит, все же делегация задач и разделение задачи вещи фактически противоположные.
(63) mymyka,
вот вот — если кодер, априори в моем посте знающий — то этого не будет никогда, а если появится — то только по его вине — задача решена неверно, а постановщику задачи конечно вовсе необязательно вникать в её реализацию, только 30/70 или как то иначе — это как раз плохой подход — есть задача, есть команда, её решающая, а когда вместо работы начинается выяснение
у кого длиннеекто главнее — тогда провал обеспечен.(64)
кодер же не должен думать в вашей схеме, он должен эффективно кодить по ТЗ, любезно проработанному для него РП? Вы сами себе противоречите. Декларируете работу в связке как way to win, но при этом объснить, чем именно должен заниматься каждый, как они взаимодействуют друг с другом, высчитать хотя бы примерный их кпд, не можете.
говоря 30/70 я имел ввиду отнюдь не столько уровень зарплаты, сколько квалификацию исполнителей. Исторически з/п на предприятии может сложиться как угодно, но в среднем по рынку обычно весьма стабильное значение.
(65) mymyka, Может я косноязычен — что кодер не должен думать точно помню что не писал. Объясняю что должен делать каждый в такой связке:
— квалифицированный специалист, ставит грамотно задачу на разработку кодеру. Под знанием предметной области следует понимать, что поставленная задача у этого специалиста нуждается только в практической преализации в рамках конкретной конфигурации. Он знает:
— Что должно быть в рамках этой системы;
— Как это должно работать;
— Что на входе;
— Что на выходе.
— зная конфигурацию сразу начинает выполнять поставленную задачу. Он знает:
— Конфигурацию (что в ней можно, что нельзя, что может быть использовано в рамках поставленной задачи);
— Умеет собственно кодить, не руша логику работы конфигурации.
Любой из этих двух мог бы решить эту задачу самостоятельно, НО:
— штурману не нужно разбираться в конфигурации, что бы не получить пресловутые «5 субконто» в аналитике со всеми вытекающими;
— пилоту нет необходимости изучать предметную область — можно сразу начинать кодирование;
— штурман имеет возможность тестировать разрабатываемый функционал на стадии реализации и при неоходимости поправлять кодера, коли того понесло «не туда», или учесть выявленные кодером нестыковки и скорректировать задачу, возможно с участием заказчика;
— кодер может оперативно реагировать на замечания одного человека, не озабачиваясь общением с тучей пользователей с их не всегда адекватными «хотелками» — это как раз не его задача и не дожидаясь момента, когда работа выполнена — а заказчик хотел не того.
Высказывания по типу
— тут вообще непонятно, что Вы хотите услышать — КПД двигателя определенной марки рассчитать можно, КПД вклада в разработку — сомнительно, получить можно только «среднюю температуру по больнице». В каждом конкретном случае может быть по разному, но меня учили «грамотно заданный вопрос — это половина ответа».
P.S. Что ж так всех здесь тянет пределы «может/не может» у оппонента/собеседника оценивать?
Споры о тактике и стратегии сферического коня в вакууме.
(56) Просто не надо обращать внимание на троллей. Это единственное что могу добавить.
(63) mymyka,
Это один из вариантов штурмана. Причем если взять пару десятков последних проектов в моей практике, то это наиболее популярный вариант.
В т.ч. и те проекты где в роли штурмана приходилось выступать мне. К тому моменту я уже далеко ушел от сферы ИТ и даже не имел прямого влияния на руководителя отдела ИТ. Был директором по развитию и в сферу моей зоны ответственности входили вопросы оптимизации внутренних процессов между всеми подразделениями компании, включая филиалы и франчайзи.
Надо ли говорить что оптимизация процессов в большей своей части тесно связана с ИТ. Соответственно работали сообща. Образовывались команды проектов, где почти всегда была пара штурман+пилот и была некая группа заинтересованных лиц, с которыми согласовывались требования и результаты, и шла тесная взаимосвязь. Но эту группу требовалось всегда держать подальше от пилота, что и описано в статье.
Сейчас сменил характер деятельности, вышел на рынок с новым продуктом. Развиваю его. В основном занимаюсь продажами. Но при этом проданные проекты еще нужно реализовать, и вот тут снова вступает в дело эта схема. Я продал и описал задачу, взял роль штурмана, а разработчик пилотирует.
Это если смотреть с точки зрения одного проекта. Если смотреть с точки зрения штурмана, то тут мы снова, частично расходимся с аналогией, т.к. в течении недели мне приходится пересаживаться в разные экипажи, и работать с разными пилотами. Получается что пилотов много, а штурман пока один 🙂
Более того, аналогия на то и аналогия, что она не равна 100%, скажем встречаются проекты, где заказчик достаточно компетентен и его можно смело заводить в проект, он может общаться с пилотом на уровне штурмана, понимая особенности этой роли. Это редкий случай, но он встречается на практике.
Потому спорить конечно можно долго о том что в жизни все не так как в этой аналогии. И как не странно — оказаться правым 🙂 Другой вопрос что аналогия показала суть идеи, ее основу. Она понятна тем, кто хочет что то понять. Кто то не хочет — но это право и выбор каждого.
(0), всё интересно кратко и просто описано. То, что эта схема не покрывает все сто процентов случаев всевозможных жизненных случаев, очевидно и не стоило такого длинного обсуждения. Мне на практике эту схему довелось отработать лишь однажды, на олимпиаде по программированию, на первых курсах универа. Схема тогда доказала свою эффективность. Мне довелось разбивать большую задачу вплоть до подпрограмм (каждую из которых я мог бы написать и сам, но не хватило бы времени, ибо оно было крайне ограниченно) в которых перечислял входные выходные параметры и словесный алгоритм получения вторых из первых. Мои два товарища, не зная какие именно части задания они делают (ну или зная, но в общих чертах, без деталей), реализовывали поставленные задачи, после чего я осуществлял сборку из готовых блоков, где до поры до времени стояли заглушки, позволяющие мне работать в тестовом режиме.