В форумной полемике - все заправские управленцы, но у кого есть реальный опыт?

Реальный опыт в управлении разработкой ПО в малознакомой области?
Какое место в иерархии вы занимали? Есть ли у вас набор проверенных методик и собственно, откуда он у вас появился?

Интересны проекты от пяти программистов.

(0) развести РП на меренье письками не удастся

а к чему вам это?
на работу приглашаете?

(0) В Рарусе разрабатывал

я по скруму работаю

ах да

надо прогов не кормить, посадить в темноту и холод. Тогда КПД значительно возрастет

(6) в точку. Полуголодный мерин работает лучше.

На самом деле, я считаю, что в управлении разработкой ПО - есть своя четкая методология. Сейчас, чо греха таить - всё происходит как-то по наитию.

Какие компетенции необходимы. Как участники распределяют их между собой. Что на входе, что на выходе.

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

Там где "не программирую" - вообще "отрыв от стола". Проги шушукаются с юзерами, что то выдают на гора. Кто то доволен, кто то нет.

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

Что такое вообще управление разработкой? Скажем, на одну ступень ниже чем заказчик.

Пристально смотреть на прогов и кричать "Давай, давай, не уставай!"?

Быть способным полностью заменить любого прога?

Иметь в голове всю схему/архитектуру ПО?

Но это же бред какой-то.

Это называется "менеджер проекта" причём не только для ПО но и для любого другого проекта тоже.

(8) свят-свят-свят..

(3)
Что же касается проектов на 1С - это вообще (внезапно) какая-то утопия. Как там вообще можно что-то удержать в рамках? Всё равно что на JS ERP-системы ре-а-ли-за-вы--вы-вы-вы-вать.

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

(12) А чего - на js-е можно много чего интересного написать и даже целую систему.

(8) А вот тебе для поломки головы ещё одно событие. Как по твоему архитектура такой системы, как W2K, в головке должна укладываться. В одной, в нескольких, в скольких нескольких?

(15)
Этого я себе вообще не представляю. Да ладно W2K, я не представляю себе менеджмента захудалой игры.

(16) Ну, игра - это вообще всё очень просто - логика игры - несколько листков А4 - а всё остальное - это визуализация.

(17)
Есть опыт? Знаешь, например, сколько людей делали тот же LIMBO?

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

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

(19)
Это не то. То, что может сделать один человек - немного. Каким бы гением он не был.

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

(20)
Это всё какие-то общие слова, которые все раньше слышали. Результат, сроки..

Кто отвечает за отдел, который рисует персонажа? Что у него на входе? Что на выходе? Какие показатели успешности, оценки его работы?

(21) Когда больше десяти, то там уже и менеджер не один, так как управление - это целая наука.

Игры всё же не то, там изрядная доля творчества.

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

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

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

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

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

(27)
-- " нужно, чтобы был кто-то, "
Супер. Нужен кто-то. Есть ли в голове исчерпывающий набор компетенций для написания, скажем, УТ?

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

(28)
--а сегодня квартиру покупает - накуй не сдался твой проект - мозги другим заняты.

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

Сегодня он квартиру покупает, завтра у него проект на стороне, послезавтра его девушка бросила.

Риск должен быть минимальный.

Ни одна система не пишется в один присест

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

(31) + мало того, что рано детектить, а учитывать эту ситуацию, иметь возможность быстрой нормализации ситуации, и чтобы это всё имело отражение в бюджете.

(31) наука управления - сродни науке статистика - в целом по больнице одна температура, а вот в каждой палате по разному

(29) Просто, сначала пишется модель учёта, а потом уже это программируется - проколы на этапе модели потом программированием не исправить.

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

(36) модель можно потом переделать. УТ 11 на идеальных пользователей ложилась хорошо - пока не столкнулись с реальностью - потом уже меняли модель походу дела.

конечно это значительно дороже - но такова жизнь

(36)
Я не понимаю.

Сколько надо денег/времени (конкретно вам), чтобы написать УТ, скажем, на C#. Конечный результат - что то типа конфигуратора + конфа. Язык C#.

(38) "Идеальный пользователь" - это изначальная ошибка модели.

(37)
Ну как-то представляю. А как иначе? Иначе - объектно-ориентированное программирование по 1С-овски.

Приходим на объект.
Ориентируемся.
Программируем.

(40) Всё зависит от того, что вы хотите получить.
Если вы хотите конфигуратор, то изначально нужно ставить задачу - сделать систему разработки приложений, а уже потом на этой системе делать что-то.

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

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

(43)
Я хочу конечный продукт, изначально WEB-ориентированый, избавленный от слабых сторон 1С. Язык C#.

Сколько денег и времени?

Неужели нет каких-то стандартов? Я надеялся как-то получить ссылку на них.

Как разрабатывается ПО в DataArt? LuxSoft?

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

(46) Если Web-ориентированный, то нужно не забыть про javaScript и т.п.

(47) вот ты мозг выносишь - щас тебе срок тут скажут - когда не знают что ты хочешь?

(49)

-- Сколько денег и времени?

-- то нужно не забыть про javaScript.

o_O

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

(51) А тебе говорю, что на C# без знания JavaScript ваша фигня просто не взлетит вообще - какие тут сроки - ваш проект похоронит любой бюджет.

(47) стандартов дофига - тебе уже перечислили. Основные - PMBook, Экстремальное программирование, ТОС и еще много других - зависит от подхода к проекту.

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

Ну я руководил разработкой, даже "1С:Совместимо" получал.

ЭЭЭ

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

Agile-методики... Мне кажется, что они применимы к каким-то простым задачам. Заказчика послушали, спринт нарисовали, за неделю уложились, показали - все довольны.

Но зачастую, заказчик не врубается, что на его пожелание "А", тянет за собой реализацию "B,C,D".

(47) вот тебе стандарт wiki:Rational_Unified_Process
Всем стандартам стандарт. Если делать чётко по нему, будет долго, дорого и, скорее всего, никому не нужно

(55)
Чо та наколеночные подходцы какие-то.

(58) "Agile-методики... Мне кажется, что они применимы к каким-то простым задачам."

Почитай, откуда есть пошло экстремальное программирование. Вряд ли _это_ можно назвать простой задачкой... (ссылку искать или сам найдёшь?)

Вот тебе еще стандарт wiki:Microsoft_Solutions_Framework
Его даже прочитать до конца я не осилил

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

в малознакомой (особенно как архитектор) - нафиг нафиг... а так

(63) ага еще у SAP - ASAP есть. В итоге все об одном - крутится вокруг PMBook

(62)
Та же фигня. Запомнил только про оценку среды - понял, что этого-то я и не учел. Всё остальное - ничего нового.

Парни, я о другом. О ДРУГОМ.

Декомпозиция, оценка - всё это супер, но это всё ИЗВЕСТНО.

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

1. Хочет УТ на Web-e. 1C не хочет. Предыдущие франи круто лажанули - так что всё что угодно, но не 1С.

2. Служба такси, 10 000 заявок в день. Куча абизян, которые распределяют эти заявки, куча ошибок. Хочет всё автоматизировать.

3. Нужно написать прогу для какого-то заумного медицинского оборудования. От этого оборудования будут зависеть жизни людей.

4. Представитель морского порта. Нужно решение, автоматизирующее размещение контейнеров с учетом "я-щаз-всё-расскажу".

Ну вот, четыре клиента с деньгами.

Ваши действия?

какой-то странный опрос и рассуждения тем более

"управлении разработкой ПО в малознакомой области"

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

(66) Стричь деньги не отходя от кассы.

(67) Можно.

(67)

-- а можно чем-то вообще управлять в малознакомой области?

IBM в свое время вывел из кризиса человек, который в IT вообще на понимал. Спроси у него.

(62)
1 Три студента - дипломный проект.
2 Один студент - курсовая работа.
3 Один студент - дипломный проект.
4 Пять студентов - практика.

(70)
Пятый клиент.
Вот задача.
v8: Нужен отчет, визуализация....

???

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

(72)
Но ведь крупные корпорации всё же как то делают софт умопомрачительного масштаба.

(71) Студенты уже кончились, но, думаю, что не более трёх.

(73) делают. Но сколько средств они вкладывают в области "вокруг программирования"? В математику, в технологии тестирования?

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

(75)
Стоп. На софт решающий VRPwTM для транспортной компании  ты отвел три человека и на сраненький отчет - тоже три?!? Что то неладненько с оценкой то!

(76) багофикс говорит о том, что "баг ушел в продакшен", несмотря на все ухищрения разработчиков и многоуровневое тестирование

VRPwTM = VRPwTW конечно же

VRPwTW - Vehicle Routing Problem with Time Windows

ничего сложного, главное понимать бизнес-процессы

Методологию вбили на прошлой работе - теперь бы избавится от него

(0)
Не, я не руководитель по природе, это не мое.
Не могу заставлять других работать, мне это неинтересно.

Я сам по себе, одинокий воин охотник.

Что то никак разговор в нужное русло повернуть не получается.

O_O

(66) отдай клиентов - а там я разберусь

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

Один человек может сделать некий продукт, который имеет некие рамки. Так или иначе - за эти рамки продукт не выйдет. Потому что его делает ОДИН человек.

Что если задумка грандиозна, ресурсы есть (деньги), но велик риск всё профукать?

(85)=>(71)

(86)
Я не умею управлять другими.
Не дано.

Остальные "что если" неуместны.

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

(88)
Блин, почему сразу негативный расклад "пинать и заставлять"?

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

(89)
Моя недолгая практика начальника отдела ИТ показала, что надо.
иначе все просто забивают на работу, дисциплина падает.

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

(89) ну, тогда, выше же писали уже про пмбук.

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

(77) А в чём проблема - теория графов ими изучена - пусть работают.
Просто, учёт на Web-е - нужны специалисты по браузерам, по серверному ПО и реализацию протокола.
А в визуализации - не сказано на чём - пусть ребята потренируются.

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

Запросто могу нахмурить брови, сделать зверское лицо и прорычать: "Работать, негры!".

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

Некоторые РП-шники программирование то не знают. Главное доверять команде.

И бюджеты соответствующие иметь.

(96) с бюджетами любой дурак сможет (кто сказал "депутат"?)

(96)
-- Главное доверять команде.

Это не управление. Так - повезет/не повезет. Да "команда = куча программистов" - ни о чем.

Из кого состоит команда в вашем понимании?

(96) куча книжек по проектам есть на озоне. Мне понравились.

Одно но... Где в России взять такие деньги?

100

http://www.youtube.com/watch?v=-uGdaKFboHo

(99)

-- Одно но... Где в России взять такие деньги?

Это другой вопрос. Вопрос кроилова можно решать по разному - имея в голове ЧЕТКУЮ картину КАК НАДО. От от неё уже уменьшаться, ужиматься, идти на косспромиссы...

Пока всё не станет зависеть от админа Васи.

Команда 5 человек - 1 год в Москве - 10 миллионов. Найти инвестора сможешь?

(101) Урезать - не проблема - проблема, как урезать так, чтобы взлетело и не завалило.
Некоторые удачные решения не взлетают только потому, чтобы вышли на рынок сильно недоделанными и просто оттолкнули пользователей.
Также, нужно понимать, что полностью вылизанное решение может не найти места, так как его обогнали конкуренты, у которых всё не очень вылизано, но уже работает.

(102) возможно это минимум

(102)

o_O

Да у меня как-то не стоит задача ни искать пять человек, ни инвестора.

Команда 5 человек - каким компетенциями обладает эта команда?? Должна обладать? Могла бы обладать?

В чем вопрос то??

P.S. Что за продукт способны сделать 5 человек за год?

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

(106)
Ну.. Поделись? Вкратце.

Может литература какая-то, ресурсы...

(106)
Причем опыт управления 1С-овскими проектами интересно выделить в отдельную тему. Так как очень специфично.

(107) тебе опыта отсыпать? :)
Уточни вопрос(ы) тогда

(109)
-- Может литература какая-то, ресурсы...

(109)
Как ты добиваешься слабой связанности/модульности в 1С-проектах?

Как держишь прогеров в рамках?

Как тестируете?

Чем заменяете интерфейсы в 1С?

(109)
Какими компетенциями обладают люди в твоих проектах?

Как они их сочетают?

Какую роль выполняешь ты?

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

(111)
>Как держишь прогеров в рамках?
1. проектирование
2. формализация стандартов и правил (aka база знаний)
3. планирование
4. учет задач и работ, план-факт по времени
5. бизнес процессы

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

>Чем заменяете интерфейсы в 1С?
ни чем. Зачем их заменять?

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

(112) >Какими компетенциями обладают люди в твоих проектах? как они их сочетают?
Разными. Берут и сочетают.
Вообще вопрос малость - того-с... не продуман

>Какую роль выполняешь ты?
чаще всего - главную, но не редко и просто надзорную

(113)

>Чем заменяете интерфейсы в 1С?
ни чем. Зачем их заменять?

Но их нет в 1С.

--так ты о чем спрашиваешь-то? Про управление процессом или про архитектурные решения?
Одно вытекает из другого.

Если прогов десять человек (да они все здоровые ребята), то рано или поздно они полезут туда, куда им лезть нельзя.
Причин на это - МИЛЬОН.

Нельзя запретить физически прогу доступ к БД. Постеснялся спросить, насоздавал регистров, чего-то в них там считает...
Когда выясняется - переделывать поздно.

(114)
--Разными. Берут и сочетают.
--Вообще вопрос малость - того-с... не продуман

Да куда ж продуманней..

Для строительство дома надо:
1. Архитектор одна  штука.
2. Начальник строительства - одна штука.
3. Прорабы - 4 штуки.
4. Каменщики - 4 штуки.
5. Кровельщики - 2 штуки.

Из головы. Один человек может быть и кровельщиком и каменщиком. Вот набор компетенций и их сочетание.

Что такое - надзорная роль - я не понимаю. Равно как и ГЛАВНАЯ. )))))

Результатом этапа "Проектирование" что является?

(115) интерфейсов нет? о_0 давно?

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

>Нельзя запретить физически прогу доступ к БД.
можно. У нас ни у кого нет прямого доступа к конфигурации продуктива. Продуктив обновляется комплектами поставки, их натягивает поддержка, у которой есть доступ, но нет понимания и желания делать что-либо, кроме Конфигурация...Поддержка...Обновить конфигурацию.

(115)
-- интерфейсов нет? о_0 давно?

O_o С самого начала.

http://msdn.microsoft.com/ru-ru/library/87d83y5b.aspx

Я не про GUI конечно.

(117)
--можно

Нельзя. Я не про БД продуктива, а про БД вообще.

(116) надзорная роль - это когда я смотрю в отчеты, которые кажут показатели процесса разработки и отклонения от нормы, а потом пишу что-то вроде: "Евгений, у тебя вот эти два ТЗ покраснели, сделай с ними что-то" или "Константин, в этом ТЗ ни описания изменений в спецификации нет, ни объекты метаданных не заполнены, я не согласую помещение, т.к. чо вы там менять собрались, я не понимаю". Прямо в процессе не участвую, только воздействую на отклонения.
Главная роль - это, когда я беру ТЗ на стадии, когда там только требования, и делаю вот эту вот магию, в результате которой у нас есть, что муйнуть на продуктив. При этом и лавры мои, и ответственность моя.

Результатом проектирования является, логическая модель - процессы, функции, объекты данных, профили, операции. Подробности тут http://v8.1c.ru/model/ можно пошукать

(119) к бд sql тоже доступов нет ни у кого. Есть некий тестовый инстанс MSSQL, к которому у некоторых есть доступ для тренировочно-исследовательских целей и всё.

(118) да нафиг в большинстве случаев интерфейсы не нужны. По моему опыту, единственное место, где лично мне бы пригодились полиморфизм и наследование - это те прожекты, в рамках которых надо в Документоборот добавлять свои бизнес процессы. Там реально можно в три слоя матом покрыться, пока заставишь свой процесс с комплексным работать. В остальном 1С - предметно-ориентированная среда, в которой ты уже говоришь на языке предметной области на столько, на сколько это вообще возможно и ни какой ООЯП тебе такой абстракции без фрэймворка не даст.

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

Когда сам пишешь ПО - как-то редко заботишься о модульности, слабой связанности и т.п.

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

Ты вроде бы и развел по углам, но они все равно как-то смешивают понятия, делают не по проекту (я пробовал, у меня тормозило!).

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

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

Качество контроля на другом уровне. Прогу просто тяжело сделать ошибку. Да что там контроля - качество распределения работ! Любой прог может сделать модуль, не имея понятия - что происходит в других модулях и чему служит его модель.

В 1С это реализуемо путем бесконечных соглашений.

(120)
-- Подробности тут http://v8.1c.ru/model/ можно пошукать

Ты в этой конфе работаешь?

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

(123) ну... когда она была взята из коробки с надписью СППР, да

(120)
-- к бд sql тоже доступов нет ни у кого.

)))

В 1С ты в ПРИНЦИПЕ никуда за пределы DAL не выходишь.
Я об этом говорю.

(124)

В 1С - да.

+(124) "и не может быть ей запрещено" = "и противоречащие этому правилу действия не могут быть запрещены системой"

(120)
Когда ты выполняешь надзорную роль - кто пишет ТЗ, которые "покраснели"?

Кто составляет ФТ на основе которых пишутся ТЗ?

На основе чего составляются ФТ?

(126) и СЛАВА БОГУ! Потому, что высокооплачиваемые специалисты могут обрушить чудовищный огненный дождь на головы несчастных пользователей. Прочие же специалисты могут намного больше дамага нанести, дай им доступ. Так что я только счастлив, что хотя бы дропнуть ни кто ни чего не может...

(129) ФТ пишут аналитики (они, правда по-другому называются). Другое подразделение. На основании чего - я в дшэ ни бубу, но думаю, что должны - на основании полного и законченного описания модели бизнес процессов компании.

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

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

(133)
Это ты мисту делал?

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

В ветке разговор о разработке ПО.

А не про то, как круто 1С-ник притерся в торговой фирмочке, которая всё IT отдала ему на откуп, платит ему сотку и горя не знает.

Разные вещи.

(133)
Сколько проектов ты запустил/завалил, Asmody?

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

(134) мисту делал Волшебник, я ее только поддерживаю

... и мочалок командир!

(137)
Не знаю, что такое масштаб области. Не знаю - зачем ты вообще про него упомянул. Если в рамках моего вопроса - у тебя один успешный проект, который ты запустил в 22 года?

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

Так что с наскоку брать такие крепости больше не хочется.

"С наскоку" - это не только "открываем конфигуратор - погнали!", а и "ну, теперь то всё будем делать по ТЗ!!"

Хочется ЭФФЕКТИВНО делать вещи, усилиями классных НЕСКОЛЬКИХ спецов. Ибо я верю, что то, что может выйти из под рук такой "команды" - заведомо превосходит результат работы одиночки.

(140) так ты медаль хочешь? Ну так с этого бы и начал, а то не зайди Asmody, до ночи бы до сути не добрались...

-- так ты медаль хочешь?

Какую медаль??

(141)
Да как с тобой до сути то добраться? )))

Роли: главная, надзорная и... И народ.

ФТ пишут аналитики, ТЗ - так и непонятно кто.

Интерфейсы не нужны, а программисты доступа к БД не имеют.

Конечно, сложно будет...

(140) а ты разве священник, чтоб я перед тобой исповедовался?

(138) И делал я её, кстати, с нулевыми знаниями PHP и MySQL, хотя программирование вообще, конечно, знал, и языком запросов владел.

Свой первый большой проект я реализовал в 1997-1998 году, это была конфигурация с нуля для расчёта зарплаты в строительной фирме. Там был полный набор всех видов расчётов, включая прогрессивный подоходный налог, всевозможные льготы, расчёт по среднему, налог с матвыгоды и прочая фигня + полный набор отчётности в налоговые органы, включая электронную.

(145)+ Т.е. это всё было в мои 18 лет и когда я стал совершеннолетним, я уже был руководителем проекта. Считай, родился.

И по теме ветки: вот это моё творение http://1c.ru/news/info.jsp?id=4499 (точнее, творение группы товарищей под моим руководством)

(0) Сколько работаю, только один раз видел человека с профессиональным подходом к разработке базы данных. Чел был архитектором и использовал профессиональные средства моделирования баз данных.
Пока не была создана модель базы данных, никто не писал ни строчки кода.

Получается, что все остальные - не профессионалы.

(144)
Так ты ж сам начал. o_O

(148)
Ну... Ведь проектирование БД != проектирование всего ПО.

(147) А вот моё http://1c.ru/news/info.jsp?id=1114

(150) разработка баз данных на одинес, в подавляющем большинстве случаев, сводится к подавляющему отсутствию документации, отсутствию модели ПО и разработка осуществляется по принципу "куда нелегкая вынесет"

(150) если вы хотите разработать серьезное ПО (не базу данных) то вы не на тот форум пришли :-)
Здесь ни разу не поднималась тема об использовании в работе профессиональных средств моделирования.

(0) "Реальный опыт в управлении разработкой ПО в малознакомой области? "

Тут нет таких специалистов, имхо.

(153) поднимались. И копья ломались только так. Только в случае с 1С, весь этот шум вокруг CASE-средств — не более, чем пук в лужу.

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

поэтому иногда фейл это вин, а вин предтеча фейла
http://habrahabr.ru/post/145960/
ждём результаты по доминикане

(155)+ из свежего
v8: 1C + Case средства
Посоветуйте CASE TOOL для описания бизнес-процессов

(156)
(про Ворд) - фига се! O_O

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

(160) да модель нарисовать — дело несложное, хоть и небыстрое и утомительное. Только практического толку от этих моделей и презентаций мало

(161) думаешь, в гугле и майкрософте тоже сначала кодируют, а потом думают? :-)

(161)
-- да модель нарисовать — дело несложное

Ну если речь идет о "товары на складах" - тогда да.

(161) это смотря, с какой целью рисовать. Если для презентации, то это действительно не имеет смысла

(162) в приложении к разработке на 1С толку от таких моделей мало

(163) ты пробовал реализовать складскую логистику с планированием размещения? или, например, расчет потребностей?

(166)
Сэр, нет, сэр!

Мне вдвойне теплее от того, что "расчет потребностей" херачится сразу синим кодом, сэр!

(164) вот тут http://mista.ru/dot/ похоронена старая волшебная статья. там, в том числе, есть схемы на основе структуры из первой УПП. много ли в них толку?

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

(167) кстати, "расчет потребностей" - чистая математика. рисовать там "модель"?

(168) смысл профессионального моделирования по не сводится к построению графов, презентаций в поверь пойнте и рисованию стрелок в акскссе.
Это процесс, не менее трудозатратный, чем непосредственное программирование коллективом разработчиков.
Смысл процесса заключен в полном моделировании будущего ПО, чтобы разработчики потом сели и тупо закодировали.
Аналогично разработке того-же автомобиля. Начиная от дизайна и заканчивая размерами деталей.

(171) ты пытаешься мне доказать, что ты умнее? ОК, ты - умнее. надеюсь, тебе полегчало, и сегодня ты будешь спокойно спать

(172)
С чего это он умнее?

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

Там и посмотрим.

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

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

(172) я вообще считаю, что на мисте умных людей нет. Умные люди по ночам на мисте не сидят.

Даже те, кто с мисты в мелкие бузинесы САМ выбился - ни фига не умные, просто коммерческая жилка развита и решимости больше.

(176)
Ну вот. Приложил.

По секрету - тут пол Мисты из Штатов посты ирачит.

(178) да хоть из Гондураса. Это не показатель ума.

(178) Кстати, тоже недавно из штатов Постил, анонимайзеры быстрые :-)

(175) Видел знакомых с областью программеров. Научить программировать по ТЗ можно и обезьяну, а вот думать за обезьяну-нужно уметь ;-)

(179)
--да хоть из Гондураса. Это не показатель ума.

Разные часовые пояса, smart one. ))

(182) мне статистика по ипишникам недоступна, так что можно только догадываться...

(0) 1C Lead Software Engineer -- 6 лет
Senior Test Automation Engineer -- 3 года, заход сделан на Lead

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

+1

Все ж таки не совсем ясно, что нужно автору :)

Тут вопросы и про архитектуру - это к проектировщикам-архитекторам.
И про набор людей в команды и управление ими - читай ДеМарко и Спольски. Это уже к РП.
И про бюджеты, про риски, про стандарты, кейсы и т. п.  )))


Начинай с команды - все пишут, что это самое главное. На хабре хорошее интервью было с авторами 500px. Наши соотечественники, проект в Канаде. Пишут, что сперва ничо не взлетело. Сели, подумали. Всех разогнали, набрали очень тщательно заново. Дело пошло.

Спольски пишет тоже самое - очень тщательно отбирайте людей.

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

И т.д.

(186)
Про архитектуру - вопросы только в разрезе 1С. И это - каким образом люди выражают архитектуру в 1С.

--И про бюджеты, про риски, про стандарты, кейсы и т. п.
Не было вопросов. Если только в общей полемике.


--Начинай с команды - все пишут, что это самое главное.

***. Всё?

Когда мне делали ремонт в квартире - была бригада. Была список работ. Я знал - кто конкретно какую работу будет делать. Я знал, кто за рабочими будет следить. На часть работ я понимал, что будет в итоге; на часть - не понимал, полагался на прораба.

У здешнего люда я спрашиваю -

1. Какими скиллами должны обладать люди В ИХ КОМАНДАХ
2. Как эти скиллы называются; как люди комбинируют эти скиллы (если комбинируют)
3. Что на входе у этих людей; (Вид информации, её подача)
4. Что на выходе (Вид информации, её подача)

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

romansun, если вам непонятно, что нужно автору, может вам просто непонятен контекст обсуждения? Ну скажем, полный цикл разработки ПО в незнакомой области?

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

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

(181) Видел кучу работы на которое ТЗ написать нереально, ну кроме "расширить, углубить (с)". ТЗ возникало по ходу работы и никак иначе. Реверс-инжиниринг например никто кроме порграммеров сделать нормально не сможет, причем делать его приходилось по ходу параллельной работы выявляя расхождения. А такой работы с 1С - вагон и маленькая тележка.

гемор

отвечаю по делу

>>1. Какими скиллами должны обладать люди В ИХ КОМАНДАХ

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

Кого бы еще взял - грамотных и толковых людей на позиции архитекторов.

>>2. Как эти скиллы называются; как люди комбинируют эти скиллы (если комбинируют)

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

Была возможность поработать с аналитиками не из 1С мира. Более, скорее всего, не буду. Весьма трудоёмко выходит. Многого не знают.

>>3. Что на входе у этих людей; (Вид информации, её подача)

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

У программеров, соответственно - структурированная конктретная инфа уровня ТЗ (не путать с ТП!) и постоянная поддержка разработки со стороны аналитиков. Да и аналитики могут и сами покодить что-нить несложное.


>>4. Что на выходе (Вид информации, её подача)

Зависит от проекта и документационного набора заказчика. Где-то ЧТЗ всякие, где-то СТП, везде ПМИ (программа и методики испытаний). Рук-ва всякие. От программеров - программы )) Тестирования нагрузочные могут быть.

>>Ну скажем, полный цикл разработки ПО в незнакомой области?

В любом случае в команде должны быть аналитики, понимающие предметную область.

Если они на уровне - то суперское знание РП предметной области не так критично.

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

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

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

(0) А почему нет самого главного пункта: Я обучался менеджменту ИТ проектов.
Если есть методология, то можно управлять... Если проблемы с руководством людьми, замом берется сотрудник, обладающий харизмой в коллективе...
Для решения оргвопросов есть "меценат проекта" ит.д.

(193)
А где этому учат?

(193)
Я надеялся, что это "всплывет" в ходе обсуждения.

-- Есть ли у вас набор проверенных методик и собственно, откуда он у вас появился?

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

(192) гы

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

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

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

(195)  методик чего, опять же? Управления людьми?

Я обучение не проходил. Читаю книжки всякие, статьи, на хабре есть прям список книг must have для руководства разработки ПО

Изучал 1С:Профкейс-это наш ответ pmbok, по сути. Сам pmbok читал чутка :) коллеги вот pmi сдавали...

(191)
Как вы описываете предметную область?

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

!:-)

200

(192) Был проект по ЗУПу, зуп- на тот момент я его вообще не знал, пошел к руку- выторговал себе классного спеца, обрисовал задачу спецу, дал контакты. План работ, осметил его, накинул еще 30%, пошел защитил бюджет перед заказчиком, сделав им скидку в 10%, Далее каждые 2 недели сидел на совещании, косяков не было, но решили отжать по деньгам ибо проект выполнен спецом был ранее.


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

Как сказал мне один РП- я был в его команде

Крендель- не работай с идиотами (с)

Дешевле работать всегда с профессионалами своего дела, подбор и командообразование - вот функции РП.

Опять же если мы не говорим об рп на проекте в 10 пользователей

(201)
--РП - делает твою работу комфортной.

Ты ставишь центр оценки на место разработчика. Естественно, если ты разработчик, и тебе комфортно работать с РП - то это просто супер.

Вопрос в том, что должен делать РП, чтобы разраб думал, что ему комфортно.

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

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

(203)
Нескромно, а можно пример?

(204) >>и со стороны всего процесса кажется, что РП только слоняется и ничего не делает )))

Не кажется а так и есть :) Хорошим разработчикам пастух не нужен.

+ (205) а еще лучше пример того, что было написано с подобным стилем разработки.

(206) >Не кажется а так и есть :) Хорошим разработчикам пастух не нужен.
Очень во многом согласен. Странно мне было учить РП предметной области. Если разработчиков енсколько - то возможно оно и надо координировать, а если речь об одном ответственном, то смысла в этом нет. Даже грамотные РП с десятком проектов просот сидят на работе и делают вид что очень заняты. Пяток звонков с клиентами в неделю в поисках ответственных и согласовании сроков за работу не считаю.

(207)
Десяток проектов - это высший пилотаж. Скорее всего - вы были свидетелями проектов пущенных на самотек. Там РП для галочки - он ничего не привносит в свои проекты.

(206) (207) (208)

)))

ох... понятно, что есть такие места, где роль РП, как бы это помягше сказать.. Но мы же не о них говорит, так ведь?

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


Тема сама и я говорю о реальных активных живых программных проектах, где задействованы на фултайм, скажем, 5-10 аналитико-разработчиков.
Им жизненно необходим координатор. Причем уже на 10 человек одного РП не хватает - как минимум нужен архитектор. В каждой миникоманде (2-3 чел) нужен свой лидер.

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

(0) есть опыт на позиции от ведущего программиста тире архитектора до руководителя\лидера проекта.

используемые методики:
проектирование - экспертное мнение архитектора;
планирование - пмбок (частично).

требования к квалификации: сильный скилл аналитика плюс хорошее знание предметной области для РП as a must.
остальное - может варьироваться.

опыта управления разработкой ПО _в малознакомой области_ нет, и откажусь, если будут предложения.
возможность компенсировать какой то супер методикой отсутствие знаний предметки у РП считаю мифом.

(210)
--проектирование - экспертное мнение архитектора;

В чем проектируете?

(209)
Как-то размыто всё получается.

"как минимум архитектор"...
"5-10 аналитико-разработчиков" - я понимаю, что в 1С это way-to-go, в большом ПО, имхо, это дорога в хаос.

"Эти люди генерят только между собой письмо-поток до 30 штук в день."

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

Экстраполируя на "постройка дома":
- Майк, сколько у нас вообще этажей??
- Джон, не знаю, вроде 50!
- Но высотный регламент не позволяет строить выще 25-ти этажей?!
- У меня в проекте 50. Что делаем?
- Строим два раза по 25!
- Парни, у меня лифтовое оборудование заказано только на 10 этажей, больше поставщик не может.
- Строим без лифтов!

+(212) не надо про лифчики.

(211) где оформляем? визио, эксель.

(212)
Что писать? Издеваетесь??

Постоянное уточнение вопросов по:
Бюджеты
Сроки
Статус-отчеты работ
План-графики
Согласование встреч
Протоколы
Документация
Подключение техн. Спецов к перерписке по субвопросам, обсуждение, решение нужны ли встречи
Объемы работ
Пояснения, что входит в бюджеты и объемы и зачем это нужно
Жалобы
Ругань
Различного рода требования - ответов на столетние вопросы, требования встреч, требования документов

И тд тп тд тп

Не отвечаешь в почте - идут звонки и смс-ки

:)

(215) Что ты хочешь от ларька на 3 пользователя, там нету всего этого

Помните, как позиционировали себя БлэкБерри? Типа мы все такие корпоративные и деловые. Нащи телефоны для деловых и крутых бизнесменов. У нас офигительно удобная почта и нормальные настоящие кнопки, чтоб удобно писать.

Вот это все оттуда - почта отнимает порой по 70 % времени в день. Поневоле будешь думать о кнопках ))))