Штурман и пилот — две роли для быстрого достижения цели при разработке ПО

22.07.13

Администрирование - Роли и права

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

Гонки типа ралли «Париж-Дакар» — отличный пример.

Ресурсов одного человека уже не хватает. Нужно минимум два и такая единица уже называется «экипаж».

Как минимум определяются 2 роли: штурман и пилот.

  1. Штурман — тот кто берет на себя абстракцию, он видит путь от А до Я, смотрит на карту и делает стенаграмму (берет на себя функции коммуникации с внешним миром)
  2. Пилот — тот кто берет на себя конкретизацию, он видит дорогу и движет экипаж. Его внимание максимально сконцентрировано на конкретном моменте.

Надо ли говорить что 1+1 это не всегда 2. Часто это меньше 2-х и редко это больше чем 2. Для этого оба человека должны дополнять друг друга и доверять друг другу. Если облажается один — проиграют оба.

Моя практика показала, что в разработке такие экипажи также эффективны:

  1. Один берет на себя роль штурмана, ставит задачу и ведет ТЗ, общается с внешним миром (пользователи, клиенты …). Его внимание абстрагированно. Он не сможет сесть за разработку, даже если очень захочет. Ресурса внимания не хватит, его начнут дергать и отвлекать все те связи, которые он завел на себя.
  2. Второй разрабатывает. Он пилот. Он сконцентрирован на текущей задаче. Того что будет через два поворота он не знает. Это забота штурмана. Он отключен от всех связей, кроме связи со штурманом. Он слушает его и только его.

Тут также важен фактор доверия.

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

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

Смена роли допустима, но как правило в следующей гонке. В рамках этой гонки — каждый действует в рамках своей роли.

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

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

- Государь, Н. Макиавелли

См. также

SALE! 20%

Infostart Toolkit: Инструменты разработчика 1С 8.3 на управляемых формах

Инструментарий разработчика Роли и права Запросы СКД Платформа 1С v8.3 Управляемые формы Запросы Система компоновки данных Конфигурации 1cv8 Платные (руб)

Набор инструментов программиста и специалиста 1С для всех конфигураций на управляемых формах. В состав входят инструменты: Консоль запросов, Консоль СКД, Консоль кода, Редактор объекта, Анализ прав доступа, Метаданные, Поиск ссылок, Сравнение объектов, Все функции, Подписки на события и др. Редактор запросов и кода с раскраской и контекстной подсказкой. Доработанный конструктор запросов тонкого клиента. Продукт хорошо оптимизирован и обладает самым широким функционалом среди всех инструментов, представленных на рынке.

13000 10400 руб.

02.09.2020    122167    670    389    

714

Запрет доступа к данным по зарплате для БП 3.0 и КА 2.5

Зарплата Роли и права Платформа 1С v8.3 Бухгалтерский учет Управление правами 1С:Бухгалтерия 3.0 1С:Комплексная автоматизация 2.х Молдова Россия Казахстан Бухгалтерский учет Платные (руб)

Расширение позволяет максимально полно ограничить доступ пользователей к данным по заработной плате, а именно закрывает доступ к документам начисления и выплаты заработной платы, не позволяет просматривать бухгалтерские отчеты по счету учета зарплаты а также убирает зарплатные проводки из журнала проводок. Расширение запрещает просматривать платежные документы на выплату зарплаты, так же не доступны регламентные отчеты в ПФР и ИФНС. Расширение предлагает готовые настроенные профили "Бухгалтер без зарплаты", "Только просмотр без зарплаты".

5700 руб.

27.05.2021    32735    204    89    

165

Автоподбор ролей для профилей и групп доступа в любых типовых базах 1С УТ 11, КА 2, ERP2, Розница 2/3, УНФ 16/3, БП 3, ЗУП 3 и подобных (УФ, Платформа 8.3.14+)

Инструменты администратора БД Роли и права 8.3.14 1С:Розница 2 1С:Управление нашей фирмой 1.6 1С:Документооборот 1С:Зарплата и кадры государственного учреждения 3 1С:Бухгалтерия 3.0 1С:Управление торговлей 11 1С:Комплексная автоматизация 2.х 1С:Зарплата и Управление Персоналом 3.x 1С:Управление нашей фирмой 3.0 1С:Розница 3.0 Платные (руб)

Роли… Вы тратите много времени и сил на подбор ролей среди около 2400 в ERP или 1500 в Рознице 2, пытаясь понять какими правами они обладают? Вы все время смотрите права в конфигураторе или отчетах чтоб создать нормальные профили доступа? Вы хотите наглядно видеть какие права дает профиль и редактировать все в простом виде? А может хотите просто указать подсистему и дать права на просмотр и добавление на объекты и не лезть в дебри прав и чтоб обработка сама подобрала нужные роли? Все это теперь стало возможно! Обновление от 15.12.2023, версия 1.1.

12000 руб.

06.12.2023    2978    13    1    

34

SALE! 20%

Infostart УДиФ: Управление данными и формами

Инструменты администратора БД Инструментарий разработчика Роли и права Платформа 1С v8.3 Конфигурации 1cv8 Россия Платные (руб)

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

10000 8000 руб.

10.11.2023    3539    11    1    

34

Расширение для разграничения доступа к контрагентам и обработка для группового назначения доступа для Бухгалтерии (RLS) 3.0.143.42

Роли и права Платформа 1С v8.3 1С:Бухгалтерия 3.0 Россия Бухгалтерский учет Платные (руб)

Расширение предназначено для Бухгалтерии предприятия (версии ПРОФ и КОРП). Типовая конфигурация остается на поддержке. С помощью расширения менеджер по продажам будет иметь доступ к контрагентам и списку их документов только в случае, если он является для них ответственным. Пользователю с полными правами также доступна обработка «Назначение ответственных» для группового добавления/удаления ответственного в карточке контрагента. Есть версия данного расширения для клиентов Fresh - в магазине расширений (Fresh)

9360 руб.

14.09.2022    5759    7    4    

9

Роли для кладовщика

Логистика, склад и ТМЦ Роли и права Платформа 1С v8.3 Бухгалтерский учет Управление правами 1С:Бухгалтерия 3.0 Россия Бухгалтерский учет Управленческий учет Платные (руб)

Расширение, которое позволяет использовать отдельные роли для доступа к складским документам, для доступа к документам раздела "Производство" и для доступа к документам раздела "Покупки".

2520 руб.

21.05.2019    1692309    552    192    

133

Универсальная система оповещений в базе или по почте по произвольным условиям, расписанием, ролям и пользователям (Расширение / конфигурация для платформ 8.3.6+, для ЛЮБЫХ баз)

Роли и права Платформа 1С v8.3 Конфигурации 1cv8 1С:Управление торговлей 11 Платные (руб)

Данная система разработана как альтернатива стандартной системе напоминаний. Но имеет ряд существенных преимуществ: отображение в базе или с отправкой по почте, свое расписание, возможность фильтрации по ролям и пользователям, формирование своих запросов и макетов, шаблоны писем, работа в фоне. А также может блокировать работу пользователей при заданных условиях. Может работать в составе любой конфигурации. Имеется справка с описанием возможностей. (Обновление от 20.02.2024, версия 2.2, расширение)

18000 руб.

29.11.2019    24693    13    8    

33
Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. Manticor 66 22.07.13 10:12 Сейчас в теме
Анатолий, к сожалению рекомендуемый Вами подход не соблюдается в некоторых компаниях, в особенности у франчей. У франчей ты должен быть и аналитик и кодер и консультант, и их не инетресует быстродействие выполнения, ибо они уже получили бабло за проект от заказчика и у них одна цель- слить эту задачу на кого то другого.
2. 22.07.13 11:09 Сейчас в теме
(1) Manticor, согласен. Это редкая практика. Но так уж получается, что у нас в стране мало где практикуются эффективные методики.
Более того, внедрить тот же ИСО 20000 на мой взгляд много проще чем такие вот ролевые практики. И то редкость.

А вот переход на ролевую работу, да еще и отбор эффективных экипажей - это единичные случаи.

Много проще работу работать, да зарплату получать, с премией за выслугу лет.
3. Manticor 66 22.07.13 11:12 Сейчас в теме
(2) в уважающих себя и достаточно солидных компаниях(не франч) все эти ролевые методы уже даво применяются.
6. WanGoff 138 22.07.13 11:30 Сейчас в теме
(3) Приведите пример, пжл. Не критики ради прошу. Интересно, кто эти фирмы.

А насчет статьи - коротко, и со вкусом. Образно. Многим, наверное, тоже приходило в голову подобное. Хорошо, что кто-то зафиксировал идею.
8. Manticor 66 22.07.13 11:44 Сейчас в теме
(6) WanGoff, Ланит. Cлышали о такой?

(5) tango, к примеру Вам дадут задание - а оптимизируй ка мне выгрузку и формирование регламентированной отчетности. Как, каким образом, что именно не устраивает, какой код поменять(толи функция долго выполнятется, то ли запользован не тот тип данных)- все повешено на одного программиста-консультанта. А вообще взять ту же УПП - практически во всех проектах по внедрению нужно прелопачивать код процентов минимум на 40 а то и все 60. Это из практики).
Умолчу о тарелке с супом(...
9. tango 506 22.07.13 11:51 Сейчас в теме
(8) Manticor, хороший пример

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

если основа сделана, то кодирование там может свестись вовсе к паре строчек

если "штурман" понял, что это за строчки, ему быстрее написать их самому, чем объяснить кодеру

если не понял - зачем он вообще?

более интересно было бы разобрать пример с заменой ЗУПовских запросов на что-нибудь более вменяемое. Но это уже будет сопоставимо с разработкой полноценной конфы
58. RustIG 1351 26.07.13 12:05 Сейчас в теме
(9) tango,
более интересно было бы разобрать пример с заменой ЗУПовских запросов на что-нибудь более вменяемое. Но это уже будет сопоставимо с разработкой полноценной конфы

:) посмотрите статью http://infostart.ru/public/195627/
10. WanGoff 138 22.07.13 12:04 Сейчас в теме
(8) Честно говоря, не очень много. Хорошая контора? Как она ведет проекты? Судя по всему, они внедряют Бухгалтерию и Консолидацию в основном. Своих продуктов нет.

И все же насчет подхода я выступлю в защиту. Ваши примеры, друзья, верные, они легко разбивают позицию автора. Однако, мне видится, что такой подход применим при более-менее комплексном внедрении, когда есть архитектор и более-менее понятно, как будет развиваться разработка.
11. tango 506 22.07.13 12:11 Сейчас в теме
(10) WanGoff,
есть архитектор и более-менее понятно

вопрос остается
УПП: должны ли видеть место нового функционала среди типовых шняг оба - и кодер, и архитектор,
или кодер может спокойно себе кодировать хотелки юзеров, транслированные к нему архитектором?
13. WanGoff 138 22.07.13 12:30 Сейчас в теме
(11) tango, по-хорошему, нет. Не оба. Архитектор должен корректно встраивать функционал. А кодер - он должен реализовывать. Как раз реализуется описанные в статье механизмы - архитектор видит картину в целом, а кодер - текущую ситуацию (например, будет ли код мешать коду, реализующему другой функционал)
Manticor; +1 Ответить
4. tango 506 22.07.13 11:18 Сейчас в теме
ну хорошо. аналогия красиво подана.
внимание вопрос: если речь идет о развитии функционала УПП, кто из этих двух отвечает за недублирование метаданных (использование существующих)?
7. tango 506 22.07.13 11:32 Сейчас в теме
(4) tango, по ходу - УПП должны знать оба
16. 22.07.13 15:26 Сейчас в теме
(4) прошу обратить внимание на строчку "Как минимум определяются 2 роли".
Архитектор там :)

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

Но если это лишь заезд в рамках какой-то серии? Экипаж - это лишь часть всей команды. За их спиной трудится иногда еще большая группа. От главного тренера, который их инструктирует, до тети Маши, которая им вкусные пирожки готовит. Да и экипажей в таком случае может быть много.

В таком случае архитектор, этот тот кто писал им ТЗ. Или принимал участие в написании ТЗ.
И более того, архитектор во время гонки никуда не испаряется. Он находится на прямой связи со штурманом.
Но даже архитектор понимает, что общаться надо со штурманом, а не с пилотом. Пилота трогать - в момент гонки. Можно не слабо так гонку просрать )
5. tango 506 22.07.13 11:30 Сейчас в теме
наверное, ключ сабжа - это:
две роли для быстрого достижения цели

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

а в реалиях 1с получается проект типа беловского: есть верткий 1с-менеджер, и есть голодные кодеры за тарелку супа
(ничего личного, по этой схеме работают практически все франчайзи, не только Белов)
12. tango 506 22.07.13 12:14 Сейчас в теме
прикол еще в чем:
кто будет платить, если код придется переделывать?
14. tango 506 22.07.13 12:41 Сейчас в теме
короче, резюме
роли - это роли
а вот будут ли эти роли разнесены по разным учаснегам - вопрос масштаба проекта

архитектор на большом проекте не наблюдатель за интеграцией нового функционала в типовуху ("будет ли код мешать коду"), а координатор между своими же кодерами. но тогда столь красивая аналогия, предложенная ТС, уже не работает
штурман шумахера михаеля не штурман шумахера ральфа
15. adhocprog 1139 22.07.13 14:54 Сейчас в теме
Грамотно написано.
17. mymyka 22.07.13 15:57 Сейчас в теме
Неудачная аналогия. Если архитектор и кодер работают одновременно, то это не Париж-Дакар, это Париж-Куда_приедем_туда_приедем. В этом случае штурман не нужен, т.к. цель максимально быстро приехать из точки А в точку Б не стоит. Единственная цель в этом случае - это показательно с дымом из-под колес и ревом мотора отбить бабки спонсора.
Если же работа выполняется последовательно(как и должно быть), то какой смысл кормить 2 человек? 2 пилота, самостоятельно подготовивших маршрут заранее, пройдут его за то же время, что и один экипаж штурман+пилот дважды.
И не надо про мифических кодеров, не разбирающих в азах построений бизнес-процессов. Такой лапоть ничего вам не накодит, или время на разжевывание ему ТЗ будет непомерно большим.
18. tango 506 22.07.13 16:04 Сейчас в теме
(17) mymyka,
И не надо про
отчего же. 4 + уже есть
19. 22.07.13 16:16 Сейчас в теме
(17) mymyka,
>> И не надо про мифических кодеров, не разбирающих в азах построений бизнес-процессов.

давайте о мифических кодерах которые разбираются ) какова их доля если взять 100 среднестатистических 1с-программеров? 1,5%?

У нас в стране даже 99% руководителей не смогут отличить бизнес процесс от бизнес процедуры и план от прогноза. Программисты тем более.

Далее, я не говорил о том что эта методика единственная верная. Я ж сказал что она применяется там где есть сложная цель и ограниченный срок. Как мы знаем, в 80% организаций никто проектный подход не использует, нет сроков и нет целей. Есть просто куча программистов и общий ФОТ, который распределяется согласно градусу загнутых пальцев и числу сертификатов на нос. В этом случае такой метод бесполезен.

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

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

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

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

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

Вот. Много разных ситуаций может быть. И от сюда может быть много решений. В статье описано лишь одна из 1000 возможных ситуаций. Есть еще 999, одну из которых вы встретили на своем жизненном пути. Вот опишите то как там все устроено - почитаем с удовольствием. И придет в комментарии кто либо и скажет что не так оно все и все по другому и будет он иметь ввиду еще одну ситуацию... ту самую 998-ю. Ну и т д.
Alex_E; lefthander; +2 Ответить
20. mymyka 22.07.13 17:09 Сейчас в теме
(19)Ну дак и что вам накодит такой
среднестатистический 1с-программер

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

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

просто /рукалицо, no comments. Если вы вынуждены руководить людьми, опыт которых заключается в развозе дисков ИТС длиной в 3 месяца, остается только посочувствовать и серьезно обсудить с начальством соотношение з/п программистов и ожидаемого от них выхлопа.
З.Ы. Связка ИТ-руководитель(70т.р.)+слабый прог(30тр) ВСЕГДА будет слабее, нежели 2 средних прога(50т.р.+50т.р.).
22. 22.07.13 17:36 Сейчас в теме
(20)(21)
Господа ) я не 1с-ник.
Просто умею создавать информационные системы. Мне не важно на каком программном продукте они будут вертеться. Лижбы приложение было не совсем убитое и этого мне достаточно чтобы запустить систему и чтобы она начала приносить пользу предприятию.

Но ввиду такой специфики мне часто достаются проекты на самых разных платформах и стеках технологий. Соответственно работаю с разными масштабами систем (от 10 до 1000 пользователей) и типами программистов (от php до 1с).

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

То что вы их не встречали - бывает такое. Вот только не надо тут додумывать факты, которые не соответствуют реальности и существуют только в ваших головах.
teflon; anchovy; +2 Ответить
23. tango 506 22.07.13 17:48 Сейчас в теме
(22)
Господа ) я не 1с-ник.
с этого надо было начинать
24. 22.07.13 17:50 Сейчас в теме
(20)
>> З.Ы. Связка ИТ-руководитель(70т.р.)+слабый прог(30тр) ВСЕГДА будет слабее, нежели 2 средних прога(50т.р.+50т.р.).

Это заблуждение. В моей практике был случай, 2-х похожих проектов, где связка "руководитель"+"молодой прог" обогнала связку "10 средних и сильных программистов". Затем расклад сил чуть поменялся, но не сильно.
А когда подвели итоги за год то получили:
1. В одном случае затраты по проекту составили порядка 3 млн руб и охват порядка 20 процессов
2. Во втором случае затраты по проекту составили порядка 7 млн руб и охват порядка 3 процессов

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

Когда подняли статистику по работе, то выяснили что в случае с п.1, 80% это были улучшения и 20% ошибки, а в случае с п.2, вся эта толпа в 80% задач закрывала ошибки которые сами же наделали и только 20% их задач были связаны с улучшениями.

Но чтобы это увидеть, нужно в отделе ИТ внедрить ИСО 20000. А много ли где оно есть?

Это все позволило мне сделать выводы, с которыми я поделился в этой статье.

Я не прошу с ней соглашаться, но прошу не высасывать фантазии из своей головы и не пытаться их выдать за факты.
AlexanderEkb; +1 Ответить
25. tango 506 22.07.13 17:55 Сейчас в теме
(24)
Это заблуждение. В моей практике был случай
:)
27. mymyka 24.07.13 10:28 Сейчас в теме
(24)
был случай, 2-х похожих проектов, где связка "руководитель"+"молодой прог" обогнала связку "10 средних и сильных программистов".

это лишь свидетельствует о квалификации "средних и сильных программистов". Прог, который 80% времени правит свои ошибки это вчерашний студент, работающий на коленке без ТЗ. Назвать такого "средним" и уж тем более "сильным" язык не поворачивается.
Не надо думать, что только "руководитель" способен организовать работу. И уж тем более пытаться нелепыми теориями оправдать бесполезность такого "руководящего" звена в связке с работником, способным к самоорганизации.
ИТ-директор+2(3)средних прогов+разделение по направлениям = успех
ИТ-директор + связка(Начальник ИТ+слабый прог) = баблопильство и вечные отговорки(типичная схема в Роиссянской действительности)
Если ваш прог не может работать сам, увольте его к чертям, дайте нормальную зарплату(а не 120% оклада уборщицы), и наймите специалиста.
zqzq; teflon; Ish_2; KapasMordorov; tango; +5 Ответить
28. tango 506 24.07.13 11:12 Сейчас в теме
(27) mymyka, тут еще вопрос, а нужен ли им такой прог? несовпадение личных целей и декларированных - встречается не только на проектах.
для меня в свое время было открытием, что на собеседованиях не следует показывать себя
слишком умным
30. mymyka 24.07.13 11:48 Сейчас в теме
(28)В целой куче организаций я видел подобную ситуацию. Есть начальник ит, который последний раз программировал в далекие 90-ые. С з/п, превышающей среднюю по отрасли раза в 1.5. И бесконечная череда сменяющих друг друга вчерашних студентов с мизерной зарплатой, мизерном опытом и таким же мизерным желанием работать. Про плачевное состояние автоматизации на таких предприятиях можно и не говорить, не смотря на солидный ФОТ отдела автоматизации.
Руководитель не должен делать работу прога. Не должен писать ТЗ. Не должен вникать в реализацию проектов. Он должен предоставлять ему административный ресурс, мотивировать и помогать организовывать рабочее время.
59. Alex_E 2353 26.07.13 13:41 Сейчас в теме
Интересная статья и более чем интересные комменты. Самое смешное, ИМХО, что очень много копий тут поломато из-за путаницы в терминологии - что разные люди например понимают под словом "программист", и выводы сделанные из этого. Утверждение (30)
Руководитель не должен делать работу прога. Не должен писать ТЗ. Не должен вникать в реализацию проектов.
мне кажется нуждается в какой то степени расшифровкой, что в данном случае понимать под "программист" и "руководитель". Если программист - тот кто пишет код, то ему не зачем составлять ТЗ - он по нему должен работать, если программист пишет ТЗ и код, то он уже и программист и постановщик задач и много ещё чего, аналогично с руководителем, руководитель руководителю рознь :-).
Про связку штурман-пилот ТС написал правильно, и тут речь не о сытом руководителе и голодном программере, а о команде (экипаже) - суть ИМХО в этом.
По своей практике уже не раз убеждался, что если решать задачу не в одиночку, а вдвоем (или большим количеством) и кодить и общаться с клиентом намного непроизводительней, чем в ситуации когда кодит один (два, три ...), а второй занимается постановкой задачи, тестированием и общением с клиентом. Результат получается быстрее и более качественно.
61. mymyka 26.07.13 14:13 Сейчас в теме
(59)Я пытался донести до ТСа, что именно в рамках 1С, написание проектной документации(в простонародье называемой ТэЗэ), не привязанной к среде разработки либо занимает чудовищное количество времени, т.к. оперирует ненативными для 1С понятиями, либо сама проектная документация не исполняет своих функций полного технического описания проекта, и является по сути примитивной пользовательской хотелкой, для написания которой необязательно обладать особыми компетенциями.
Плюс не надо смешивать подход к созданию/модифицированию учетной системы, и написанию корявенького автономного приложения под Андрюшу/Делфи/Сильверлайт/и т.д. Во втором случае достаточно написать общий алгоритм работы, а техническую реализацию можно оставить прогу, т.к. она по сути влияет только на скорость работы и не более того, т.е. система 30+70 работает весьма эффективно.
В случае же учетной системы(не обязательно 1С), для создания алгоритма на обоих этапах разработки необходимо знать объекты дорабатываемой/разрабатываемой конфигурации, существующие подсистемы, учитывать влияние нового функционала на них, сквозные аналитики и т.д. При таком подходе модульная разработка становится практически невозможной и ваш мифический программист-аутист просто не сможет приступить к написанию системы до формирования полной проектной документации, что приведет только к дублировании работы архитектора(описание "на коленке", вне среды разработки, для кодера всех телодвижений в алгоритме) при системе 70+30, или перерасходу ресурсов при системе 70+50.
Результат получается быстрее и более качественно

Если исполнитель умеет планировать свое рабочее время и защищен определенным административным ресурсом от истеричных тетенек. Количество исполнителей на задачу при этом удельную производительность никак не влияет.
62. Alex_E 2353 26.07.13 14:53 Сейчас в теме
(61) mymyka,
Если исполнитель умеет планировать свое рабочее время и защищен определенным административным ресурсом от
- так все ж таки получается что программист не в автономной плавании, а защищен итд, а в качестве того же административного ресурса для защиты выступает "штурман".
Количество исполнителей на задачу при этом удельную производительность никак не влияет
- опять спорно - задачи разные, поэтому и количество исполнителей может быть различно, а в случае, когда выполненения задачи надо использовать двоих, то результат будет лучше, если один кодит, другой делает всё остальное. Причем сейчас я говорю о двух специалистах высокой квалификации и ответственность за результат несут оба.
Никто же не предлагает задачи, где достаточно одного грамотного специалиста пилить на двоих.
Пример ситуации, когда подход "штурман - пилот" оправдывается на 200% - "штурман" в полной мере владеет существом поставленной клиентом задачи и методов её решения, но слабо знаком с выбранной конфигурацией, на которой это надо реализовать. Пилот, знающий конфигурацию, потратит на порядок меньше времени на разработку, если задачи будет ставить "штурман", владеющий предметной областью.
63. mymyka 26.07.13 15:14 Сейчас в теме
(62)
в качестве того же административного ресурса для защиты выступает "штурман"

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

слабо знаком с выбранной конфигурацией

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

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

еще раз повторюсь, эти 2 сотрудника не имеют телепатической связи, им необходимо общаться, так называемому РП необходимо в устной/письменной форме трансформировать хотелки , озвученные пользователями в выбранные способы реализации в учетной системе, ему необходимо заново создать информационное поле для кодера, дабы тот мог определить в каких рамках ему действовать в случае возникновения противоречия. Причем, чем менее квалифицирован кодер, тем больше времени тратит РП на создание этого поля. Это дополнительные ничем необоснованные временные затраты.
Штурману достаточно уметь читать карту, ему не обязательно быть вторым Михаелем Шумахером. Плюс, он может читать не всю карту, а определенный ее участок. В разработке учетной же системы, такой подход не работает. Классическая реализации системы 30+70 это тех.поддержка, но путать ее с предлагаемым 70+30 не стоит, все же делегация задач и разделение задачи вещи фактически противоположные.
64. Alex_E 2353 26.07.13 15:30 Сейчас в теме
(63) mymyka,
так и появляются стандартные монструозные нетленки, допиливаемые годами, счета учета с 5 аналитиками,
вот вот - если кодер, априори в моем посте знающий - то этого не будет никогда, а если появится - то только по его вине - задача решена неверно, а постановщику задачи конечно вовсе необязательно вникать в её реализацию, только 30/70 или как то иначе - это как раз плохой подход - есть задача, есть команда, её решающая, а когда вместо работы начинается выяснение у кого длиннее кто главнее - тогда провал обеспечен.
65. mymyka 26.07.13 15:45 Сейчас в теме
(64)
кодер, априори в моем посте знающий

кодер же не должен думать в вашей схеме, он должен эффективно кодить по ТЗ, любезно проработанному для него РП? Вы сами себе противоречите. Декларируете работу в связке как way to win, но при этом объснить, чем именно должен заниматься каждый, как они взаимодействуют друг с другом, высчитать хотя бы примерный их кпд, не можете.
выяснение у кого длиннее

говоря 30/70 я имел ввиду отнюдь не столько уровень зарплаты, сколько квалификацию исполнителей. Исторически з/п на предприятии может сложиться как угодно, но в среднем по рынку обычно весьма стабильное значение.
66. Alex_E 2353 26.07.13 16:22 Сейчас в теме
(65) mymyka, Может я косноязычен - что кодер не должен думать точно помню что не писал. Объясняю что должен делать каждый в такой связке:
"штурман", владеющий предметной областью.
- квалифицированный специалист, ставит грамотно задачу на разработку кодеру. Под знанием предметной области следует понимать, что поставленная задача у этого специалиста нуждается только в практической преализации в рамках конкретной конфигурации. Он знает:
- Что должно быть в рамках этой системы;
- Как это должно работать;
- Что на входе;
- Что на выходе.
Пилот, знающий конфигурацию,
- зная конфигурацию сразу начинает выполнять поставленную задачу. Он знает:
- Конфигурацию (что в ней можно, что нельзя, что может быть использовано в рамках поставленной задачи);
- Умеет собственно кодить, не руша логику работы конфигурации.
Любой из этих двух мог бы решить эту задачу самостоятельно, НО:
- штурману не нужно разбираться в конфигурации, что бы не получить пресловутые "5 субконто" в аналитике со всеми вытекающими;
- пилоту нет необходимости изучать предметную область - можно сразу начинать кодирование;
- штурман имеет возможность тестировать разрабатываемый функционал на стадии реализации и при неоходимости поправлять кодера, коли того понесло "не туда", или учесть выявленные кодером нестыковки и скорректировать задачу, возможно с участием заказчика;
- кодер может оперативно реагировать на замечания одного человека, не озабачиваясь общением с тучей пользователей с их не всегда адекватными "хотелками" - это как раз не его задача и не дожидаясь момента, когда работа выполнена - а заказчик хотел не того.
Высказывания по типу
высчитать хотя бы примерный их кпд, не можете.
- тут вообще непонятно, что Вы хотите услышать - КПД двигателя определенной марки рассчитать можно, КПД вклада в разработку - сомнительно, получить можно только "среднюю температуру по больнице". В каждом конкретном случае может быть по разному, но меня учили "грамотно заданный вопрос - это половина ответа".
P.S. Что ж так всех здесь тянет пределы "может/не может" у оппонента/собеседника оценивать?
69. 27.07.13 10:55 Сейчас в теме
(63) mymyka,
Вот только этим штурманом не обязательно должен быть специалист по автоматизации, это может быть любой человек, имеющий вес и влияние в организации.

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

В т.ч. и те проекты где в роли штурмана приходилось выступать мне. К тому моменту я уже далеко ушел от сферы ИТ и даже не имел прямого влияния на руководителя отдела ИТ. Был директором по развитию и в сферу моей зоны ответственности входили вопросы оптимизации внутренних процессов между всеми подразделениями компании, включая филиалы и франчайзи.
Надо ли говорить что оптимизация процессов в большей своей части тесно связана с ИТ. Соответственно работали сообща. Образовывались команды проектов, где почти всегда была пара штурман+пилот и была некая группа заинтересованных лиц, с которыми согласовывались требования и результаты, и шла тесная взаимосвязь. Но эту группу требовалось всегда держать подальше от пилота, что и описано в статье.

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

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

Более того, аналогия на то и аналогия, что она не равна 100%, скажем встречаются проекты, где заказчик достаточно компетентен и его можно смело заводить в проект, он может общаться с пилотом на уровне штурмана, понимая особенности этой роли. Это редкий случай, но он встречается на практике.

Потому спорить конечно можно долго о том что в жизни все не так как в этой аналогии. И как не странно - оказаться правым :) Другой вопрос что аналогия показала суть идеи, ее основу. Она понятна тем, кто хочет что то понять. Кто то не хочет - но это право и выбор каждого.
21. tango 506 22.07.13 17:15 Сейчас в теме
ну да картинка складывается примерно такая:
есть поток студентов, слышавших, что 1с это ацтой, но денег на пиво дают
этих человеков с конторах типа Ланит называют 1с-программистами

понятно, что с этими человеками надо что-то делать, и так рождается сабж
26. umberto_nobile 5 24.07.13 09:53 Сейчас в теме
всё верно и красиво. совпадает с моим мнением по данному вопросу. Всё кроме одного. Наряду с автомобилями и грузовиками в ралли "Париж-Дакар" принимают участие мотоциклы. А это удел одиночек....
29. 24.07.13 11:13 Сейчас в теме
(26) Вот это я упустил :) Да, статья не отрицает то что существуют задачи которые можно решать в одиночку. Более того, таких задач много больше. Это основной поток.
Ровно как существуют заезды целыми группами.
Она лишь говорит о том что существуют ситуации, когда задачу эффективней решить экипажем из 2-х человек.
31. anchovy 24 24.07.13 13:39 Сейчас в теме
Наверное нужно преподносить данный подход как хороший способ решения проектных задач для команды исполнителей.
Тогда меньше было бы абстрактных возражений от кодеров-одиночек, работающих без команды, и, как следствие, задающихся вопросом "зачем мне это нужно".
32. mymyka 24.07.13 13:54 Сейчас в теме
(31)Согласен, при условии, что команда состоит из более чем 2 человек. Тогда это рациональное использование рабочего времени, иначе просто бессмысленная трата денег. Обычная задача про КПД. Потери на уровне взаимодействия между исполнителями превышают выгоды от разделения труда.
Когда это начинает понимать начальник ИТ, он вырастает до ИТ-директора.
33. tango 506 24.07.13 14:02 Сейчас в теме
(31) anchovy,
Наверное нужно преподносить
хорошая абстракция
35. anchovy 24 24.07.13 16:47 Сейчас в теме
(33) tango, Это предложение как ее избежать и не давать повода к пустословию.
Попробуйте прочитать еще раз.
36. tango 506 24.07.13 17:02 Сейчас в теме
(35) anchovy, это по-вашему так. а по-моему - чистый флуд
34. Ish_2 1104 24.07.13 15:50 Сейчас в теме
(0) К утверждениям и абстракциям Анатолия отношусь очень скептически.
Но дело в том , что взгляд с другой колокольни (т.е. непрограммиста) очень интересен на ИС.
41. 25.07.13 07:51 Сейчас в теме
(34) Спасибо!
Мне не нравится критика. Но я всегда ей рад :)
Публикация статей тут, это не попытка показать какой я умный. Это один из методов проверки идеи на прочность.
Чем мне нравится ИС, так это тем что кроме троллей тут бывают и нормальные комментаторы. Которые умеют аргументировать, отличать факты и от фантазий и правильно их подавать.

Идея - это такая штука, что кому то она может просто нравится. Кто-то ее разделяет. Кто-то становится ее противником.
Сама позиция не важна. Важна точка зрения человека и то что он думает. Если то что он думает, подтверждаемо и реально, значит это позволяет корректировать идею.

В данном случае, благодаря комментариям, эта идея уже получила существенные дополнения и корректировки.
И это не в первый раз.
Всем спасибо! :)
44. tango 506 25.07.13 10:22 Сейчас в теме
(41) один из первых признаков никчемности тезиса - охотка, с которой автор прибегает к "защите от троллей"
45. anchovy 24 25.07.13 13:12 Сейчас в теме
(41) ты достиг своей цели, молодец.
37. KapasMordorov 428 24.07.13 17:11 Сейчас в теме
Связка 70+30 как мне кажется эффективнее. Но только теоретически.
Но т.к. профессионализм в 1С оценивается очень субъективно и часто позицию "70" занимает более разговорчивый, а не более соображающий.
Поэтому 50+50 пожалуй для практики правильнее. Работают двое и подтягивают друг друга по возникающим проблемам.
38. tango 506 24.07.13 17:17 Сейчас в теме
(37) KapasMordorov,
для практики правильнее
среда для практики своеобразна. настолько, что попытки подтянуть типа MBA-"разговорчивых" мальчиков вызывают лишь кривую усмешку
39. Ish_2 1104 24.07.13 18:02 Сейчас в теме
ОФФ.
Анатолий, в статье ты пытался донести некоторые истины на ассоциативном уровне.
Сразу скажу , в любом профессиональном сообществе объяснения на ассоциативном уровне - очень дурной тон. И вот почему .
Непревзойденным чемпионом по использованию ассоциативного подхода является Христос, ему позволено.
"Для чего притчами говоришь им? Он сказал им в ответ: для того, что вам дано знать тайны Царствия Небесного, а им не дано, ибо кто имеет, тому дано будет и приумножится, а кто не имеет, у того отнимется и то, что имеет" (Мф. 13:10).
Что означает этот ответ сейчас неважно. Важно то , за кого держит большинство слушающих "вещающий ассоциативно".
Огорчу тебя , Анатолий . Ты не Мессия.
Великое искусство абстрагирования и обобщений - тебе не позволено.
Забудь ты "штурманов" и "пилотов" , анализируй конкретные ситуации "РП - исполнитель".
И народ к тебе потянется.
EarlyBird; KapasMordorov; +2 Ответить
40. tango 506 24.07.13 18:11 Сейчас в теме
(39) Ish_2, пять баллов
каждой жене по мужу
43. zqzq 23 25.07.13 10:16 Сейчас в теме
(39) +1
Вообще аналогии - простой и эффективный способ убеждения (кого угодно в чём угодно), об этом в любой книжке про "эффективные продажи" написано. Однажды на прошлой работе попробовал использовать этот приём чисто для интереса, результат превзошёл ожидания. Теперь с большим недоверием стараюсь относится к таким "доводам".
42. Rad90210 13 25.07.13 10:15 Сейчас в теме
Дела ... ни о чем ни про что ...
Водитель и штурман, Чип и Дейл, Банни и Клайд, Ильич и Крупская, 50/50 или 70/30 ... Чем больше ФОТ работникам тем меньше остается доходности... Всегда кто-то должен смотреть за дисциплиной, сроками, качеством - в случае начальник-подчиненный - есть четкая иерархия и система работает лучше, чем 10 средних программистов - которые в курилке сходятся во мнении, что заказчик идиот и что форсировать выполнение конкретной задачи глупо.
46. LexSeIch 210 25.07.13 16:48 Сейчас в теме
Мир этому дому!
Это принцип "парного программирования", используемый в экстремальном программировании. Вот как описаны его преимущества в книге :http://scrum.org.ua/wp-content/uploads/2008/12/scrum_xp-from-the-trenches-rus-final.pdf

"Вот пока несколько выводов после применения парного программирования:
• Парное программирование действительно улучшает качество кода.
• Парное программирование действительно увеличивает сосредоточенность команды (например,
когда напарник говорит: “Слушай, а эта штуковина точно нужна для этого спринта?”)
• Удивительно, но многие разработчики, которые выступают против парного программирования, на
самом деле не практиковали его, однако раз попробовав – быстро понимают все преимущества.
• Парное программирование выматывает, так что не стоит заниматься им целый день.
• Частая смена пар даёт хороший результат.
• Парное программирование действительно способствует распространению знаний внутри
команды, заметно ускоряя этот процесс.
• Некоторые люди чувствуют себя некомфортно, работая в парах. Не стоит избавляться от хорошего
программиста, только потому, что ему не нравится парное программирование.
• Ревью кода – хорошая альтернатива парному программированию.
• У “штурмана” (человека, который не пишет код) должен также быть свой компьютер, но не для
разработки, а для выполнения мелких задач, когда это необходимо – просмотра документации,
если “водитель” (человек, который пишет код) запнулся и так далее.
• Не навязывайте парное программирование людям. Вдохновите их, дайте необходимые
инструменты и позвольте самим дойти до этого."

Кстати, книга очень интересная - это опыт удачной команды по организации создани ПО.
49. 25.07.13 21:30 Сейчас в теме
(46) да, одна из причин которая натолкнула меня на эту идею, это как раз после того как я узнал что существует парное программирование. Также услышал что мнение на этот счет разное.

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

И вот понял что почти все проекты, с которыми встречался в последнее время, были в стиле 1+1. Но это не было так что оба кодили. Это всегда было так что один кодил, а второй искал недостающую информацию и прокладывал дорогу к цели.

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

И конкретно мои проекты в последнее время проходят в этой паре. Где я выполняю роль штурмана. Всячески убирая все отвлекающие факторы от пилота. Как только кто то добирается до пилота и начинает его тюкать, начинаются проблемы. Даже на совещания стараюсь не брать. Если они слишком не по делу. Только на отчеты (если по советски) или демки (если по SCRUM), где нужно показывать результат работы.
47. Evgen.Ponomarenko 567 25.07.13 20:15 Сейчас в теме
Спасибо автору за интересную тему! Ваше виденье очень сильно перекликается с идеями Брукса опубликованными еще в 75 году. http://ru.wikipedia.org/wiki/%D0%9C%D0%B8%D1%84%D0%B8%D1%87%D0%B5%D1%81%D0%BA%D0­%B8%D0%B9_%D1%87%D0%B5%D0%BB%D0%BE%D0%B2%D0%B5%D0%BA%D0%BE-%D0%BC%D0%B5%D1%81%D1%8F%D1%86 (см. Хирургические группы)

В 1С я пришел из Oracle, где цикл разработки программных продуктов на порядок дольше и команды больше.
Так вот, у нас команда на старте была такая:
Пара ИТ-Директор+его зам.
И три тройки. Закончилось ИТ отделом в 101 человек. Закончилось плохо, так как парочка ИТ директор+его зам, развалилась и развалила всю команду. А вообще деление на пары и тройки, я считаю очень продуктивной. Пары стабильней и встречаются чаще. Стабильные тройки всегда имеют внутренний конфликт, распадаются как только нарушается баланс в отношениях.
48. Evgen.Ponomarenko 567 25.07.13 20:38 Сейчас в теме
По моему опыту - пары ОЧЕНЬ ЭФФЕКТИВНЫ.
Но распределение ролей может быть различным:
Штурман+Пилот - в "сложных" с точки зрения отношений с заказчиком проектах
Первый пилот+Второй пилот - в больших проектах.
Консультат+программист - в разработке с нуля.

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

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

PS Мне кажется, что благодаря развитому инструментарию 1С - пара из первого и второго пилота наиболее жизнестойка.
nalivai-chai; +1 Ответить
50. EarlyBird 6 25.07.13 23:56 Сейчас в теме
Меня можно назвать программистом, но с большой натяжкой. Я знаю много языков. Около 10. Могу на них писать.
Причем у меня врожденное и обостренное чувство ООП. Плохо перевариваю все что не подходит под это.

А ты вообще в курсе, что ООП - это давно уже не самая крутая тема в программировании?
Поговаривают даже, что ООП отжило своё, лет примерно 10 тому назад.
Так что, хвалиться тут особо нечем.
52. Evgen.Ponomarenko 567 26.07.13 01:26 Сейчас в теме
(50) EarlyBird,

А какая самая крутая тема в программировании?
53. EarlyBird 6 26.07.13 04:24 Сейчас в теме
(52) Evgen.Ponomarenko, интернет тебе в помощь, эта информация вроде не засекречена.
54. Evgen.Ponomarenko 567 26.07.13 11:21 Сейчас в теме
(53) EarlyBird,
В данном случае меня интересовало конкретно Ваше мнение. Своё у меня уже давно сформировалось.
Можете привести методики/технологии круче чем ОПП?
55. EarlyBird 6 26.07.13 11:30 Сейчас в теме
Вообще-то сообщение (50) предназначалось топикстартеру, а не тебе. С чего ради ты сюда встрял?
И неужели ты вправду решил, что я сейчас брошу все дела и буду с тобой дискутировать о крутости ООП ?
У тебя уже сформировалось своё мнение - я за тебя очень рад. Живи спокойно со своим мнением.
56. Evgen.Ponomarenko 567 26.07.13 11:42 Сейчас в теме
(55) EarlyBird,
А нечего стебаться над топикстартером, есть что добавить - скажи по существу. А так получается стеб ради стеба.

А вообще вопрос все равно интересный. ООП не может умереть, это основа структурного программирования, в той или иной степени присутствует во всех направлениях.

И пусть топикстартер нас рассудит ;)
57. EarlyBird 6 26.07.13 11:48 Сейчас в теме
(56) Evgen.Ponomarenko,
А нечего стебаться над топикстартером, есть что добавить - скажи по существу.
Я уж как-нибудь без твоей помощи разберусь, что мне сказать топикстартеру. Ты ему кем приходишься, мамой?
68. 27.07.13 10:37 Сейчас в теме
(56) Просто не надо обращать внимание на троллей. Это единственное что могу добавить.
51. EarlyBird 6 25.07.13 23:59 Сейчас в теме
И конкретно мои проекты в последнее время проходят в этой паре. Где я выполняю роль штурмана. Всячески убирая все отвлекающие факторы от пилота. Как только кто то добирается до пилота и начинает его тюкать, начинаются проблемы. Даже на совещания стараюсь не брать. Если они слишком не по делу. Только на отчеты (если по советски) или демки (если по SCRUM), где нужно показывать результат работы.

Чувак, дай я угадаю!
Ты трудишься начальником отдела ИТ на каком-нибудь заводе. И у тебя в подчинении есть программист 1С, который под твоим мудрым куроводством что-то там ваяет нетленное (наверно, мега-CRM).
60. AVK_Alex 4 26.07.13 14:10 Сейчас в теме
Здравствуйте!
Первое - на мой взгляд, хорошая статья. Можно для себя взять хорошую идею. Пусть она подходит не для каждой задачи - согласен: где-то достаточно одного программера. Но если он начинает буксовать (не успевает, много времени уходит на разговоры с клиентами, с начальством и пр.) - возможно, стоит задуматься о штурмане? Ситуаций бывает множество и встречаются непохожие друг на друга.
И второе - не бросайтесь помидорами ;) Думаю, подобные статьи существуют для того, чтобы чему-то научиться и взять из публикации лучшее. Или дополнить мысль ТС. Зачем брать (выдумывать) плохое? Плохого вокруг и так достаточно...
67. EarlyBird 6 27.07.13 09:58 Сейчас в теме
Споры о тактике и стратегии сферического коня в вакууме.
70. Патриот 450 25.04.14 16:26 Сейчас в теме
(0), всё интересно кратко и просто описано. То, что эта схема не покрывает все сто процентов случаев всевозможных жизненных случаев, очевидно и не стоило такого длинного обсуждения. Мне на практике эту схему довелось отработать лишь однажды, на олимпиаде по программированию, на первых курсах универа. Схема тогда доказала свою эффективность. Мне довелось разбивать большую задачу вплоть до подпрограмм (каждую из которых я мог бы написать и сам, но не хватило бы времени, ибо оно было крайне ограниченно) в которых перечислял входные выходные параметры и словесный алгоритм получения вторых из первых. Мои два товарища, не зная какие именно части задания они делают (ну или зная, но в общих чертах, без деталей), реализовывали поставленные задачи, после чего я осуществлял сборку из готовых блоков, где до поры до времени стояли заглушки, позволяющие мне работать в тестовом режиме.
Оставьте свое сообщение