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

14.05.10

Команда

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

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

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

Ну и конечно, на этой платформе воплотились мечты 1с в создании конкурента для всяких ERPи иже с ними трехбуквенно абривиатурных системам. УПП родилась.

Только вот принципы работы 1Сника остались прежними. Одинокий волк чего-то там поддерживает.

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

И получается как в белом солнце пустыни.

Одна жена любит, одна одежду шьет, одна пищу варит, одна детей кормит. И все одна? - Ничего не попишешь. - Тяжелооо. - Конечно, тяжело

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

1)      Человек должен хорошо понимать предметную область разработки. То есть видеть систему глазами заказчиками. Желательно говорить с пользователями на одном языке и уметь трансформировать слова в удобоваримое, в то, что может понять и заказчик, и можно будет использовано при разработке. Я думаю, что понимание, что же нужно сделать – достаточно важный момент при первоначальной договоренности. Чтобы потом не было печально известных справедливых воплей заказчика «А мне же обещали, что будет ВСЕ, да тут не ВСЕ, я же с этим работать не могу, ОНО не работает, да я на вас в СУД… в ТЗ же явно написано ВСЕ!» Умение составить документацию нужно, чтобы ограничить ответственность разработчика и  втолковать заказчику, что «Все ходы записаны» и про это договорились, а остальные «хотелки» позже и за отдельные деньги.

Почему то когда ДОМ строят, это понятно. А когда систему, не совсем.

Не нужно объяснять, что деловое отношение к процессу поднимает подрядчика в глазах заказчика. А желание побыстрее пройти этап описание требований к системе, мол «все равно никто ничего не читает, и потом все поменяется сто раз», и побыстрее бы программировать начать чревато тем, что все что написано, придется делать. Потому что заказчики как раз программировать не умеют, а договоры читать, вот это они умеют. И если обещали ВСЕ, так берите все ЭТО и делайте. То есть по договору, и ТЗ где написано ВСЕ, возможны два варианта:

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

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

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

Насколько это легко можно узнать, грубо прикинув количество объектов метаданных в УПП.

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

3)      Написание кода в больших количествах. То есть решение вопросов алгоритмирования и отладки.

4)      Проверка того что сделано, прием работы. Если человек один, то тестировать все придется клиенту. То есть отлавливать ошибки в тот момент работы, то есть когда система должна выдавать документацию а не получается, а фура стоит и её грузить надо, не сильно приятно, я вам скажу. Ну и одна голова хорошо, а полторы всегда лучше было, это правило еще никто не отменял. Да, в одной мелкомягкой фирме 2 тестировщика на одного программиста. Спросите у клиента – как он относится, что на нем будут тестировать, то что напрограммировано?:)

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

Вывод конечно однозначный. ТЯЖЕЛО одному все это. Быть аналитиком, архитектором проекта, кодером, тестировщиком, консультантом.

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

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

Тестировщиков на 1Совских проектах нет как класса. Типа программист сам все проверит. Вот и получается, озадачен программист, а что он сделал, не знает и не видит никто. Борцы за качество пригодились бы.

Консультанты. Ну это есть. Вот бы еще технические писатели были, чтоб знать, что там с системой сделано.

Представим что проект большой. Какими людьми мы будем комплектовать отдел/команду? Перечнем из разных специальностей с разделением ответственности за каждый участок? Ну чтоб за ТЗ отвечал один отдельно взятый аналитик, за целостность архитектуры системы – архитектор, за код – программисты, за работу с пользователями – консультант? Логично вроде бы. НО НЕТ. Обычно команду наполняют толпой программистов. На вопрос почему, приходит не совсем логичный ответ «потому что программируют». Почему то на стройку не берут только тех, кто кирпичи кладет, а остальное они типа сами как-то. А когда учетную систему делают, то считают, что программист умный, разберется и ТЗ напишет, и код, и инструкцию, и по телефону отвечать будет.

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

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

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

Тогда просто нужно посчитать, во что обойдется проекту отсутствие нужного специалиста. Готовы мы рискнуть стоимостью всего проекта?

Как на стройке. На ком будем экономить? На архитекторе-проектировщике, дизайнере, прорабе, роботягах- строителях, приемной комиссии?

См. также

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

Коммуникации Бесплатно (free)

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

27.02.2024    868    0    user1561517    3    

8

Нетрадиционные методы работы с пользователями или вредные советы от опытного руководителя проекта

Мотивация Бесплатно (free)

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

13.02.2024    765    0    izybaevda    5    

15

Радио "Аналитик", 12 выпуск 2 сезона. Про архитектуру, архитекторов и аналитиков в сфере IT c Александром Кварцхава. Часть 2/2

Проектирование Проектирование бизнес-процессов Управление конфликтами Кейсы продуктов Бесплатно (free)

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

05.02.2024    437    0    Radio_Analyst    0    

1

Диагностика команды в преддверии больших изменений

Фасилитация Бесплатно (free)

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

25.01.2024    383    0    suhovnina    0    

1

Гореть, но не выгорать: как сохранить ресурс специалистов

Коммуникации Мотивация Личная эффективность Бесплатно (free)

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

15.01.2024    1700    0    KChebykina    0    

31

DevRel: почему им стоит заняться уже сегодня

Коммуникации Обучение и наставничество Бесплатно (free)

DevRel (developer relations или просто технический пиар) – направление развития и поддержки IT-бренда компании: почти как PR (Public Relations), только в центре внимания находятся технические процессы и технологии, а не маркетинг. О том, зачем DevRel нужен компаниям, какие есть форматы, кто уже запустил DevRel, что из этого получилось, и почему это становится трендом, пойдет речь в статье.

09.01.2024    1606    0    a_plastinin    2    

16

Завал в IT-компании и как с ним бороться

Коммуникации Россия Бесплатно (free)

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

25.12.2023    696    0    simon_sidoruk    1    

5

Синергия аналитика и разработчика

Коммуникации Бесплатно (free)

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

19.12.2023    823    0    Fecolka    1    

8
Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. leosoft 165 04.05.09 18:41 Сейчас в теме
Мысли правильные! Но как собрать команду?
Это очень и очень непросто!
2. Шёпот теней 1779 04.05.09 19:34 Сейчас в теме
это... фАнтастика... тАкого никогда не будЕт ... разве, что у нефтЯнников... воОооот...
3. larisab 160 04.05.09 19:41 Сейчас в теме
В чем смысл статьи? Статьи, которая ставит вопросы, но не отвечает на них. Понятно же, что проект одному не потянуть.
Есть, и давно, теория управления проектами. Уже не первый год читаются курсы, 1с создала кучу центров компетенции, есть много фирм, имеющих проектную структуру. Требования к сертификации таких центров предназначены для "насильствнного" внедрения проектных как раз технологий. А вы как будто только из леса вышли, или настолько далеки от 1с, что не знаете всего этого? Или настолько публика на ИС дремучая, что такой ликбез требуется?
4. beigka 219 04.05.09 20:26 Сейчас в теме
2 leosoft мы не ищем легких путей! надо стремится
2 Шёпот теней такое есть! в фирмах которые работают на зарубежного заказчика
2 larisab смысл статьи - посмотреть на реакцию народа, который на сайте живет. ну и пусть народ задумается лишний раз, как и с кем проекты делаются.
6. larisab 160 04.05.09 20:56 Сейчас в теме
(4) Ну не знаю... реакцию вы конечно получите, но я как то привыкла работать на конечный результат и соответственно от других жду того же. В конце статьи искала что-то типа "продолжение следует...". Если вести речь о проектах, то одно из первых, что приходится определять - "продукт", который мы должны получить в результате всей затеи. Иначе стрельба по воробьям, допишите статью, мой совет.
5. biv75 04.05.09 20:45 Сейчас в теме
7. beigka 219 04.05.09 21:13 Сейчас в теме
2 larisab я думаю что каждый сделает свой вывод. а дальше я про чтото еще напишу.
8. Ish_2 1104 04.05.09 21:29 Сейчас в теме
Автор соригинальчал : "Волга впадает в Каспийское море" .
Читатели удивлены : "Впадает , однако!".
9. beigka 219 04.05.09 22:06 Сейчас в теме
2 Ish_2 автор удивлен тому что во всем мире используются разные технологии для производства софта, а мы на коленке до сих пор. почему?
12. tsd 105 05.05.09 00:15 Сейчас в теме
(9) а почему Вы считаете, что софт производится на коленке? Если брать промышленный софт, то извините, 1С и многие фра по технологичности разработки многих западников заткнут. Если мы считаем производителями софта фри или фикси, то извините, от каждого по способностям :)

(11) а если завтра ядерная война начнется или страшный вирус гусиной куйни всех покосит? Крайне наивно считать, что в фирмах всего по одному спецу по каждой области и нет наметок где спецом временно разжится при временном дефиците. Кроме того, на нормальных проектах пишется проектная документация, которая в случае замены исполнителей позволяет войти в курс дела даже при невозможности пообщаться с заменяемым спецом.
NatalyaVP; +1 Ответить
13. leosoft 165 05.05.09 01:03 Сейчас в теме
(12) В том то и дело, что все не на одном человеке держится,
а на узких специалистах, которых много. Причем
один выбывает - всегда есть замена... Главное в другом -
буржуйские специалисты готовятся для работы строго на своем участке.
Соответственно, их можно быстрее и легче подготовить +
они очень сильно углубляются в своем участке!
А вот подготовить специалиста по всем участкам, также как
заменить такого специалиста - это проблема!
По сути имеет место разумное разделение труда.
10. leosoft 165 04.05.09 23:54 Сейчас в теме
Лет 10 назад мне довелось побывать в роли эксперта
при выборе буржуйской программы, так вот все программы
(разных производителей) демонстрировали строго по
модулям - например, "расчеты с поставщиками", "банк"
и т.д. И по каждому модулю был свой специалист,
который в совершенстве знал только свой модуль...
А остальное - это не его! Т.е. там все так построено,
чтобы от конкретных людей ничего не зависило!
Надо - обучим еще нужное количество по конкретному
модулю и далее они по жизни будут этим модулем
заниматься. Понятно, что для пользователей - это огромные
затраты т.к. по разным вопросам надо вызывать разных
специалистов. Но для внедренцев - очень удобно...
11. beigka 219 04.05.09 23:59 Сейчас в теме
2 leosoft то есть когда завязано ВСЕ на одном человеке это хорошо? а если он не дай бог помрет? проект в который вложено денех накроется. и кто этот риск считать будет?
14. Anything 89 05.05.09 03:45 Сейчас в теме
Автор поделилися опытом - молодец. Для кого-то эта статья может оказаться полезной - плюсы покажут. Хотя, практика говорит, что люди не доверяют чужому опыту.

Для многих же этот опыт - этап давно пройденный. В том числе, и для меня.

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

Но сейчас я работаю в компании, где 1 проект = 1 исполнитель (в т. ч. проект по внедрению УПП), и такая схема тоже работает.

В общем, каждому фрукту - свое время. Главное - правильная организация. Как говорится в одном слогане, think different.
Трактор; NatalyaVP; molot; Vitek; +4 Ответить
15. tsd 105 05.05.09 08:01 Сейчас в теме
(14) угу, возможно все. Только вот риски при работе 1 проект = 1 исполнитель в случае внедрения проекта по УПП до безобразия большие. Если работа идет по почасовке (бывают и такие внедрения), то глубоко пофиг, в случае проектного внедрения ну очень высока вероятность срыва работ.
16. Anything 89 05.05.09 09:12 Сейчас в теме
(15) Согласен. Но в данном случае риски минимизированы, проект идет на окладе. :)
17. beigka 219 05.05.09 09:17 Сейчас в теме
2 Anything как связаны все риски проекта с формой оплаты исполнителю? или проект делает специалист который работает у заказыика? и заказчик чуствует что он обо всем позаботился?
18. Арчибальд 2706 05.05.09 09:27 Сейчас в теме
Статья изобилует риторическими вопросами. Именно риторическими, поскольку ответа не требуют/не имеют. Однако вопросы эти возникают по ходу решения задачи создания трехбуквенной системы неправильным путем "все в одном". Т.е. сначала принимается решение, создающее трудности на ровном месте (внедрить УПП), затем ищутся пути для героического преодоления этих трудностей. Или, по аналогии, сначала принимается решение упразднить на предприятии должности финансиста, экономиста, главного инженера, главного технолога, директора по сбыту, директора по снабжению... , далее везде, с целью замены всей этой команды суперкрутым центром управления - ясно, что это не один человек, а некий коллективный разум.
Придя к абсурду (коллективному разуму) начинаем его структурировать, разделять полномочия, разграничивать доступ, «иерархизировать» - и приходим к той же древовидной структуре управления, только с излишними горизонтальными связями, вносящими в управление хаос/непредсказуемость.
Ну не нравится нам старая яблоня. Срежем ветку, сделаем прививку.
Прижилось – займемся другой. Если хотим увеличить риски, тогда давайте вырастим нужное нам дерево сбоку – вдруг потом удастся пересадка целиком!
В терминах 1С: если требуется комплексная автоматизация учета и управления, то про УПП следует забыть.
SatanClaws; LavS; NatalyaVP; gavril; +4 Ответить
19. beigka 219 05.05.09 09:50 Сейчас в теме
2 Арчибальд то есть лучше сделать чтото свое? и оно конечно будет лучше УПП?
20. Арчибальд 2706 05.05.09 10:12 Сейчас в теме
(19)Ну, не с нуля. Что есть хорошего - использовать. Торговлю там, кадры, бухгалтерию. Что нужно добавить - дописывать (постепенно). Например, управления производством в УПП нет, так и не нужно его туда впихивать - пусть будет отдельная конфигурация. Управление всем проектом необходимо по двум параметрам - общая стратегия/концепция и интерфейс подсистем.
Т.е. я проповедую распределенную обработку данных с регламентированным (и, соответственно, автоматизированным) документооборотом. Считаю, что такой подход повышает устойчивость системы, ее сопровождаемость, гибкость (толерантность к внешним воздействиям), и снижает риски при внедрении, а также пресловутую совокупную стоимость владения.
Вопрос-подковырку "свое лучше, чем УПП" отметаю с негодованием. Как можно сравнивать точно негодную вещь с неизвестно какой?
Аксиома1: без УПП предприятия работали. Аксиома2: автоматизация на базе 1С приносила пользу. Гипотеза "с УПП они работают/будут работать лучше" достоверного подтверждения не имеет.
21. Арчибальд 2706 05.05.09 10:32 Сейчас в теме
+20 Хочу уточнить: я не против УПП в принципе. Если УПП в основном подходит - а я думаю, что предприятию, скажем, по расфасовке пластикового профиля, подойдет, - вперед и с песней. Только это не будет КРУПНЫМ проектом, подразумеввшимся в статье. В статье прямо указано, что УПП требует грандиозных доработок, т.е. не подходит.
В принципе возможна подводная лодка-самолет, существовали даже действующие опытные образцы. Но рекомендовать их фирме на том основании, что она занимается и подводными и воздушными перевозками мне совесть не позволит.
alf2005q; gavril; Душелов; +3 Ответить
22. beigka 219 05.05.09 11:04 Сейчас в теме
2 Арчибальд я еще не видила ни одной самостятельно разработанной конфигурации, чтоб она просто покрывала возможности типового продукта, не говоря уже чтоб была лучше.
и не говоря уже про целостность, наследуемость и прочее и прочее.
обычно получается чтото вроде дома с наростами пристройками. в лучшем случае.
потому что из сэкономленных денег и на специалистах на которых сэкономили, когда спец один чтото ваяет, никто не проверяет что он делает, не говоря уже об общей идее.
чтоб нормально чтото сделать нужна команда с полным составом. причем желательно с опытом совместного успешного внедрения.
25. Арчибальд 2706 05.05.09 12:12 Сейчас в теме
(22)Я и не призываю делать аналог чего-то типового с нуля. Есть УТ - пусть работает, если подходит. Я утверждаю, что десяткам тысяч чеков ККМ в БД финансиста не несут полезной информации, и значит, вредны. А нарядам на разгрузку вагонов нечего делать в бухгалтерской базе.
Целостность заключается не в хранении всех данных в одом файле, а в тематическом каталогизировании. Большие системы нежизнеспособны, если подсистемы не могут существовать автономно (это и не подсистемы тогда вовсе, если их выделить нельзя).
Кстати, пример разработанной с нуля конфигурации, с запасом перекрывающей типовой продукт 1С, известен - посмотрите в сторону КАМИНА.
Итак, БОЛЬШАЯ система ДОЛЖНА состоять из подсистем, иначе она развалится. Если на движение Луны Солнце будет действовать сильнее, чем Земля, спутника у Земли не будет.
Прежде, чем обсуждать состав команды, нужно определиться с целью. И если этой целью будет создание сложной системы, то в составе команды обязана отазиться структура системы (состав подсистем)
Трактор; LavS; +2 Ответить
23. Шёпот теней 1779 05.05.09 11:54 Сейчас в теме
работали мы в R\3 ... знакомы ваши слова и идеи ... на такие изуверства у наших товарищей никогда не хватит ни умов ни денег ... у основной массы товарищей даже на УПП не содержатся более чем одного программиста а уж создавать проекты ... а если всЁ это помножить на наше законодательство - ни одно импортная программа не в с остоянии этого произвести - сколько ни создавай проектных групп ... а по Зарплате - кранты всем ... говорю это со знанием дела - проработал в этих проетах с "бешенными" бабками на освоение - не стройте иллюзий ...

... что немцу хорошо - для русского смерть ...

... статья - это хорошо... а верить в неЁ это идеалистический тупик...

...вооОоооттАкоЕестьмнЕние....
24. beigka 219 05.05.09 11:56 Сейчас в теме
2 Шёпот теней Просто душа просит порядка...
28. Шёпот теней 1779 05.05.09 15:10 Сейчас в теме
(24) ... согласен ... выражаете общее желание ПОРЯДКА ... но его не будет ... нет никаких к нему оснований ... потому, что бухгалтерия не нужна как учЁтная система она нужна для сдачи внешних отчЁтов ... а про комплексные решения и говорить нечего - мы для них не созрели ... нам проще политические решения создавать без всякой экономической составляющей ... нет условий и нет двигателей вот и нету движителя ...

... это столько РАЗ обсуждалось что уже оскомину набило, к сожалению ... а УПП вообще никак не соответствует своему назначению - стоимость его внедрения и обслуживания зашкаливает все мыслимые и не мыслимые суммы ... и поэттому никогда и нигде не окупается ... это уже показатель того, что ЗАЧЕМ еЁ покупают производства непонятно... видимо слоган " УПРАВЛЕНИЕ производственным предприятием " директорам не даЁт покоя .. ОНИ думают если еЁ купили - то уже сразу и начнУт УПРАВЛЯТЬ .... дураки какие-то...

воооОоооттАкоЕнИкАкОемнЕниЕ...
29. vip 05.05.09 15:20 Сейчас в теме
(28) > потому, что бухгалтерия не нужна как учЁтная система

Золотые слова...
26. Арчибальд 2706 05.05.09 12:16 Сейчас в теме
+25 Комплексная автоматизация и внедрение УПП, как говорят не только в Одессе, две большие разницы. Комплексная автоматизация на основе УПП - третья разница (мифическое событие).
27. beigka 219 05.05.09 13:18 Сейчас в теме
2 Арчибальд разработка на основе УПП была взята как пример создания чегото действительно сложного и комплексно охватывающего учет, а не маленькие доделки сбоку.
про мифические события не будем тут. тема не про то.
30. beigka 219 05.05.09 15:32 Сейчас в теме
тема статьи не то как тяжело внедрить УПП, и вообще не про УПП и не про директоров которые не знают что бы им еще внедрить.
тема про то что без полного состава команды толково проект не сделаешь.
31. Шёпот теней 1779 05.05.09 15:45 Сейчас в теме
(30) вы меня удивляете ... это то же сАмое утвЕрждать - трава зелЁная а небо синее ... коллектив как команда нужна везде где есть задачи где физически один человек не в состоянии сделать... особенно в современном мире где разделение труда, где специализация настолько глубока что уже и программисты друг - друга не понимают ...

... во-вторых - любое внедрение начинается с верху а не снизу... ну наберЁте вы команду профи-единомышленников и будЕте работать сами на себя и что...? кому польза...? работа ради работы... НЕТ.. сначала ваша работа кому-то должна быть нужна а потом уже коллектив, руководители... сначала Цель, потом Задача а уж потом Исполнители ... триЕдинство так сказать ...

... если хотите тАк кАк ВАМ хочется - то ради бога... оставайтесь в своЁм мирЕ непОнятых мирОм вАших вОзможностей ...

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

... фАнтазируйте... если это вам помогает... удачи во всЁм от доброго сердца... в конце-концов: плох тот солдат который не хочет стать начальником департамента Информационных Технологий и навести ПОРЯДОК ...

вООООт....


64. RustIG 1351 05.05.10 10:57 Сейчас в теме
(30) > тема про то что без полного состава команды толково проект не сделаешь.

Рекомендую
... что-то есть общее
65. tango 506 13.05.10 04:05 Сейчас в теме
(64) не любит Серёжа Гладков 1сников :)
66. Шёпот теней 1779 13.05.10 09:39 Сейчас в теме
... работать в команде - это талант ...

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

... исходя из 1...3 пунктов собрать команду - бесполезное дело ...
... создание постоянной команды - маловероятно из-за "разовости" проектов ...
... создание коллективов при больших предприятиях - тут фактор экономии скажется и то же маловероятно см. п. 1...3 ... даже на УПП на предприятиях с численностью более 300-500 работает по одному программисту ...

... вот ...

п.с. по поводу ссылки в (64) .... благими намерениями сами знаете куда вымощена эта дорожка ...
п.с. (65) ... ? ... а кто ИХ любит - то ... ??? ...
68. beigka 219 13.05.10 12:06 Сейчас в теме
(66) статья годовой давности, странно что на неё отвечаете. вообщето, да, из асоциальных элементов команду не сделаешь и вообще мало чего сделаешь) а насчет гений, то да, вы правильно написали - в кавычках) я считаю что хороший программист - это мастер. а с "гениями" - тяжело работать.
(67) - не понимаю про что это вы
69. Шёпот теней 1779 14.05.10 08:22 Сейчас в теме
(68) по поводу (67) ... нуууу ... типа началось КОЛЛЕКТИВНОЕ обслуживание на 8.2. смерть франчам ...

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

п.с. ну и что годовой давности - видимо для Rustig это актуально ... по-моемому ЭТО всегДА актуально ...

... ВОТ ...
71. beigka 219 14.05.10 09:31 Сейчас в теме
(69) ну коллективное обслуживание УПП это нонсенс. натянуть одну сложную систему на другую сложную систему тяжеловато) если конечно упп сейчас на бухгалтерии из 3х пользователей не начили ставить такие скорые умельцы.
а вообще анонс имеет подтекст "мы коробку продаем и базу вам развернем, а назвали это красивым словом". а потом толпа обиженых - "нам втюхали упп, а оно нам не подходит, а денег заплачено уйма, и есть ощущение, что нас надули".
обслуживание упп можно назвать групповым, только в одном холдинге с единой учетной политикой, но тогда это не сильно дешево все равно.
73. Шёпот теней 1779 14.05.10 09:40 Сейчас в теме
(71) ... тендненции обозначены ... правила устанавливаются .... остаЁтся вопрос реализации ...

(70) ...

А-социальный. человек – тот, кто ушел от общества.
Анти-социальный. человек – тот, кто в оппозиции к обществу.

... думается мне - разница огромна между ними ! ... первые это "набор" а вторые "комплект" ... )))

п.с. ... и ей тОООжЕ привЕт ... )))


... ВОТ ...
80. SatanClaws 143 29.06.12 14:22 Сейчас в теме
(66) Шёпот теней,
1) всяко бывает
2) Да (или близко к этому). На самом деле то, что со стороны выглядит как "гениальность" - зачастую просто по другому работающие мозги (ноги асоциальности тоже отсюда растут).
3) Нет, нет и еще раз нет. Хороший программист любит "красивые" решения. Иногда они сложнее очевидных, иногда - даже проще.

Но даже если он весьма асоциален - зачастую это никак не мешает ему хорошо вливаться в комманду.
"Общительность" (открытость к общению) требуется, фактически, только от тимлидера и хелпдеска.
Все остальные вполне могут функционировать в рамках минимального регламента общения (например, тестировщик сообщает обнаруженные баги программисту в определенной форме) - который [регламент], к слову, обычно спокойно принимается асоциальными людьми.
81. support 4484 29.06.12 14:30 Сейчас в теме
(80)
Как пасти котов. Наставление для программистов, руководящих другими программистами.




Программист подобен кошке, которая гуляет сама по себе. Так
32. beigka 219 05.05.09 16:36 Сейчас в теме
очень хорошо что все понимают что трава заленая а небо синее и что делать серьезные вещи нужно командой.
34. venger 2121 05.05.09 17:26 Сейчас в теме
(33) Холивар фореве:-) Покой нам только снится:-)

http://infostart.ru/blogs/1055/
35. venger 2121 06.05.09 12:40 Сейчас в теме
(34) воспринимайте это как веселую игру в "столкновение мнений", не принимайте близко к сердцу:-) Более того, рад, что Вы не стесняетесь и пишите статьи - это хорошо! А критика - это самое ценное, что можно получить, ибо даже проигрывая в споре - Вы выигрываете, на самом деле, т.к. получаете живую, актуальную информацию на интересующие Вас темы, знакомитесь с аргументами других точек зрения, начинаете видеть проблему более многогранно...
36. detec 136 07.05.09 00:12 Сейчас в теме
Для начала посоветовал бы автору на будущее внимательнее вычитывать статьи. Постоянно мелькающие несогласованные предложения и ошибки пунктуации никак их не украшают.

Теперь по теме. Должен сказать, что проекты внедрения, состоящие не только из программистов, существуют :))! Причём в непрофильных конторах! На нашем проекте внедрения в торговом холдинге национального масштаба, кроме программистов, работали 2 постановщика задач. Я совмещал роли тестировщика и технического писателя. Один программист отвечал за архитектуру, был у нас и административный руководитель, частично выполняющий роль руководителя проекта внедрения. Конфигурация полностью самописная.
Такой состав команды сложился частично в силу обстоятельств, частично подбирался руководителем проекта. Внедрили успешно, из-а изменений в ТЗ затянули со сроками процентов на 30. Из формальных недостатков - действительно, содержать такую команду недёшево. Поэтому, чтобы такая команда сформировалась, кроме денег у предприятия необходимым условием является любовь собственников к автоматизациии и генерирование ими новых идей
37. beigka 219 07.05.09 11:11 Сейчас в теме
2 detec хорошо что хоть где то есть команды... спасибо за мнение.
38. ZLENKO 398 08.05.09 11:05 Сейчас в теме
Много людей нужно когда нужно много денег "освоить". В целом риски по проекту слабо связаны с количеством людей в команде (ну есть конечно банальная нехватка ресурсов для решения каких то конкретных задач по проекту, но это уже тактика управления проектом - можно что то перенести, что то перераспределить). 90% проектов на 1С вполне реально сделать силами 1-3 человек.
39. пользователь 08.05.09 12:16
Сообщение было скрыто модератором.
...
40. beigka 219 08.05.09 12:45 Сейчас в теме
2 iov маленьким фирмам маленькие корабли. и эксель. большим фирмам - большие. в статье - про большие.
41. molot 285 08.05.09 23:11 Сейчас в теме
Забавно... а у меня получается одному :) И заказчик доволен. Я эт не прелестями бренчу, а к тому, что написано ФУФЛО.

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

Хотя, если честно, совсем одному, конечно, сложно и скучно.
42. beigka 219 08.05.09 23:34 Сейчас в теме
2 molot рада за вашего заказчика.
но у меня есть СВОЕ мнение.
и если еще чето захотите у меня тут прокоментировать, не упоминайте про прелести. я все таки барышня - мне не понравилось.
43. LavS 165 14.07.09 01:43 Сейчас в теме
Что бы не говорили, а мне статья понравилась... Как будто про меня написано:) Приходится быть и архитектором, и программистом, и тестером... а последнее время ещё аналитиком, консультантом и организатором... Хотя от последних я стараюсь открещиваться, но не всегда получается... Кризис, блин, чтоб его... Так это ещё пол беды... А ведь веду не один проект... а 2 отраслевых решения поддерживаю(одно из которых самописное, а другое - надстройка над УПП)... Ну да ладно, я уже привык:) А за статью - спасибо, некоторые мысли наконец в голове правильно уложились:)
44. LavS 165 14.07.09 01:43 Сейчас в теме
Что бы не говорили, а мне статья понравилась... Как будто про меня написано:) Приходится быть и архитектором, и программистом, и тестером... а последнее время ещё аналитиком, консультантом и организатором... Хотя от последних я стараюсь открещиваться, но не всегда получается... Кризис, блин, чтоб его... Так это ещё пол беды... А ведь веду не один проект... а 2 отраслевых решения поддерживаю(одно из которых самописное, а другое - сильно доработанное УПП)... Ну да ладно, я уже привык:) А за статью - спасибо, некоторые мысли наконец в голове правильно уложились:)
45. beigka 219 14.07.09 09:35 Сейчас в теме
2 LavS спасибо на добром слове:) очень приятна положительная оценка. хоть ктото меня понимает:)
46. Арчибальд 2706 14.07.09 10:02 Сейчас в теме
(45) Попытаюсь добавить положительных эмоций. Мне статья тоже понравилась в той части, где анализируются трудности проекта "все в одном" и пути преодоления оных трудностй. А моя предыдущая критика относилась не к самой статье, а именно к методу автоматизации "все в одном" - его я продолжаю считать весьма малопригодным для существующих реалий учета.
48. Ish_2 1104 18.09.09 20:55 Сейчас в теме
(46) Да простят меня галантный Арчибальд и уважаемая автор, поднимём планку разговора.
Статей о том что всё непросто при автоматизации - много.
Призывов к Заказчикам : Вы ж там смотрите , не экономьте - тоже немало.
После статьи я как читатель пожимаю плечами : Ну, да... И что ?

Предложите хоть что-нибудь , за что можно было бы зацепиться.
Идею , метод , подход , намёк , к конце концов , для разрешения проблем автоматизации. Почти наверняка, предложение Ваше будет ошибочным , но зато будет что обсудить.
Если планка слишком высока , то можно описывать и анализировать конкретные
примеры автоматизации удачные и неудачные.
На мой взгляд , это гораздо интереснее, чем повторять многократно описанные трудности автоматизации и автоматизаторов.
55. Арчибальд 2706 20.09.09 10:32 Сейчас в теме
(48) В постах 18, 20, 25 я сделал чисто конкретное предложение. И, естественно, безошибочное. Поскольку - работает (спросите хоть у Че), а практика - критерий истины.
Говорят, что трехбуквенные системы тоже работают.
Пусть говорят (с) Малахов.
56. Ish_2 1104 20.09.09 10:53 Сейчас в теме
47. Трактор 1246 18.09.09 19:48 Сейчас в теме
Хорошая статья. Весьма понравилась, хотя, конечно, представление УПП как свет в окне неверное. УПП хорошо для своей части проектов. Не столь большой как хочется внедренцам УППы.
49. Ish_2 1104 18.09.09 21:36 Сейчас в теме
Я извиняюсь. Осмелюсь на утверждение :
Внедрение программных продуктов на мелких и средних предприятиях в 80% случаях осуществляют реально 1-2 чел. Это плохо , но так есть.
И нет никаких оснований полагать , что в ближайшее время что-то изменится.

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

Но, на мой взгляд , гораздо важнее привести конкретные рекомендации для
этой основной массы автоматизаторов , чем призывать к разумному разделению труда : архитектор, прог.. и т.д.
50. KEVE 18.09.09 22:51 Сейчас в теме
Спасибо за Вашу статью. Жаль что увидела её позже - не махала бы шашкой на данном форуме. Но видимо я из тех "кто учится на своих ошибках". Я немного с другой стороны и может не столь убедительно пыталась достучаться "о необходимости команды для создания качественного продукта". И ряд тех-же людей, которые пытались Вас с этой статьёй "заткнуть" применили эту же практику и со мной. Я всегда считала, что околокомпьютерные люди имеют хорошо развитое логическое мышление и прекрастные способности абстрагироваться. И была в шоке. Основная масса моих оппонентов явно обладала "конкретикой" мышления. Думаю Вы заметили данный дефект в полемике по этой статье. Когда Вы пытаетесь достучаться об общей проблеме (приводя примеры для убедительности), данные индивидумы цепляются к приведённому примеру, и пытаясь изобразить из себя всезнающих, начинают обсасывать данный пример и пытаются абстрагировать его на всю проблему. ( Я пыталась встать на защиту бухгалтеров, заходящих на сайт, и достучаться что они те бесплатные тестеры, которые могут помочь в утюжке "произведений" наших уважаемых программистов. И что чистый программисть это "кодировщик" в хорошей команде разработчиков. Но была поднята на смех. В шоке от уровня данных "специалистов" я прекратила полемику, поняв что "желающих слышать" нет. Поэтому увидев Вашу статью была рада. Я не один в поле воин- есть единомышленники. Спасибо. Теперь уверена, что мы " не последние магикане"
51. Ish_2 1104 18.09.09 23:22 Сейчас в теме
(50) Я извиняюсь. Общий посыл Вашего того выступления мною разделялся.
Но форма , на мой взгляд , была несколько резкой и неудачной.
Впечатление было смазано , по-моему опять же, ненужным выпадом против Душелова.
52. KEVE 19.09.09 19:57 Сейчас в теме
(51) Да не было конкретного выпада ни против кого. Я просто высказывалась риторически на предмет доброжелательности и терпимости к окружающим не обладающим знаниями в вашей области, но в тоже время возможно являющимися спецами в другой. И невозможность поотдельности достигать весомых результатов в решении глобальных задач, ведь истина рождается только в единении. Также меня коробит интернетовский сленг. Согласна, есть профессиональный сленг - к нему я отношусь спокойно, и часто сама пользуюсь. Но инетовский это деградация, ведь им в основном пользуются люди невысокого уровня развития (в простонаречье "овощи") коих в сетях более 50%. Они просто по другому не могут выразить свои мысли и чувства. Но зачем же всем Вам - людям с высоким интелектом опускаться до них, лучше пытаться их тянуть до себя. И если кто-то конкретно на себя примерил мои определения, то я в этом не виновата. В тот момент я представления не имела с кем веду полемику. Хотя для меня нет разницы кто мой аппонент во время дискуссии. Единственное что мне понравилось - как красиво господин Душелов вышел из ситуации.Вот тогда-то я и поинтересовалась его личностью. Не скрою - была удивлена. В следствии чего возник вопрос: а зачем данный господин так себя вёл. Вывод напросился сам- для разогрева интереса к чему-либо (как в токшоу) Приношу извенения господину Душелову-ничего личного
53. Ish_2 1104 19.09.09 20:27 Сейчас в теме
(52) А что , Елена. Достойный ответ.
Вам по секрету скажу : я интернетовский сленг тоже не воспринимаю.
Странные эти люди интернетчики.
А среди программистов (это тоже - между нами ) людей с высоким интеллектом не больше , чем в других областях.
54. KEVE 19.09.09 21:39 Сейчас в теме
(53)Спасибо Вам Игорь за понимание. Возможно Вы и правы, но хотелось бы верить, ведь изначально потенциал высокий. Но у каждого есть право выбора своего жизненного пути, и воздаяние за этот выбор каждый получает своё. Но Вы меня порадовали. Наши ряды крепчают. Удачи Вам.
57. beigka 219 20.09.09 22:33 Сейчас в теме
2 Ish_2 гораздо важнее привести конкретные рекомендации для
этой основной массы автоматизаторов - ну... конкретные рекомендаци для таких специалистов одну статью не влезут. наработка опыта + прочтенные книги, системные знания, тренинги и кропотливая работа с применением опыта. во всем мире разработка програмного обеспечения деятельность с разделением труда, у нас же часто занимаются без образования, и не известно по какому принципу подобранные управленцами. вообще странная критика - лучше бы про чтото другое написали. я выбрала такую тему для своей статьи, может есть еще куча интересных и важных тем, но мне было интересно написать именно про то что написано.
59. Ish_2 1104 20.09.09 23:31 Сейчас в теме
(57) В Вашем соображении , что не стоит указывать автору о чем писать есть резон.
Но я хотел обратить Ваше внимание на то , что ресурс для публикации выбран специализированный - здесь нет инвесторов. И второе : проблема разделения труда в команде внедренцев малоактуальна для огромного , подавляющего большинства пользователей ИС.
Сам я слаженную команду внедренцев , могущих потянуть большой проект, живьём не встречал. То , что встречал, тоже называлось командами, но впечатление было очень грустным.
Я позволю себе предположение : профессиональная слаженная команда внедренцев - товар не просто дорогой , но редкий и штучный.
Возможно , такое предупреждение для людей, имеющих соответствующий бюджет для внедрения , будет нелишним.
Шёпот теней; +1 Ответить
60. beigka 219 20.09.09 23:38 Сейчас в теме
(59) ну, может инвесторов нет, но возможно есть руководители IT департаментов, которые подбирают подрядчиков.
а команды нужно не встречать, а создавать вокруг себя. ну и беречь.
61. Ish_2 1104 20.09.09 23:47 Сейчас в теме
(60) Призывом на призыв. Неплохо.
58. beigka 219 20.09.09 22:33 Сейчас в теме
2 KEVE спасибо за хорошие слова, я рада что статья пригодилась
62. CheBurator 3119 20.09.09 23:53 Сейчас в теме
> больше конечно для мелких фирмочек, поскольку действительно большие объемы информации семерка не выдерживала. Истории про то как отчетик формировался всю ночь, чтоб утром посмотреть…
- это на основании откуда такие проблемы? воту меня сведения что типовые 8-ки в среднем нормально юзать до 50 пользователей при активной работе - дальше начинается такая же заточка как и на прочих системах...
63. CheBurator 3119 20.09.09 23:57 Сейчас в теме
> Как на стройке. На ком будем экономить? На архитекторе-проектировщике, дизайнере, прорабе, роботягах- строителях, приемной комиссии?
- ни на ком... будем писать мегадорогие проекты, которые мало кто будет покупать.. поэтому уже готовые проекты будем пытаться продавать по такой цене, чтобы покрыть месяцы простоев...
Шёпот теней; +1 Ответить
67. Шёпот теней 1779 13.05.10 09:58 Сейчас в теме
... кстати о коллективах ... ВЫ это видели : http://www.it-grad.ru/services/arenda-1c/upp ... ВОТ ...
70. tango 506 14.05.10 08:54 Сейчас в теме
асоциальность - не причина провалов проектов. уголовнки, ..., ... - прекрасно поднимают свои бабки.
Шепот, тебе привет от Ольги
72. beigka 219 14.05.10 09:36 Сейчас в теме
(70) я представляю как уголовник будет с пользователями по фене говорить)
а вообще я про то что давно в спорте известно. лучше слаженная работа команды, когда 1+1 > 2, чем одна звезда, которая может в любой момент бросить все и, например, запить, подвергая успех дела под удар.
74. Abadonna 3958 14.05.10 10:16 Сейчас в теме
(0) Не обиду автору, но даже прочесть не смог! Есть же проверенные экранные шрифты, которые нормально смотрятся.
А от шрифта статьи у меня просто голова закружилась, достаточно просто на экран глянуть было.
75. beigka 219 14.05.10 12:38 Сейчас в теме
(74) скорее не в обиду тех кто сайт сделал. я со шрифтами не игралась. стандартная настройка отображается.
не читайте, раз голова кружиться) ничего страшного не случиться
76. beigka 219 14.05.10 12:42 Сейчас в теме
77. Abadonna 3958 14.05.10 12:46 Сейчас в теме
(76) Thank you :!: ;)
Согласись - ведь куда лучше смотрится, хоть на вкус и цвет...
78. Abadonna 3958 14.05.10 12:59 Сейчас в теме
Во! Теперь смог прочесть. Внесу свои 5 копеек.
На ДЗНВА мы строили (и ведь построили!) ERP на...спокойно!.. 7.7.
Было нас там аж 5 программистов. Правда, к нашей чести надо сказать, что мы при этом "вытеснили" оставшийся еще с советских времен АСУ в количестве 30 (!) человек.
Так что все зависит от начальных условий, задач, уровней спецов. Я уже как-то писал (без обид чистым 1С-ам), те проггеры не поднимались до 1С, а снисходили ;) Потому вопросов написания дополнительных внешних приложений, нужных драйверов, длл просто не стоял. Надо - и писали. С другой стороны на предыдущем месте работы (завод примерно того же профиля, но поменьше масштабом), один проггер вполне прилично поддерживает УПП.
79. SatanClaws 143 29.06.12 13:46 Сейчас в теме
интересно, чем большой проект на 7.7 отличается от большого проекта на 8.1

Наверное, "отсутствием" ООП в виде 1С++ (и даже зачатков ООП в объектах обычной 7.7 без всяких приблуд)? Или, может, отсутствующей необходимостью наличия тестировщиков, хэлпдеска и (главное) идеолога проекта?
Оставьте свое сообщение