|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
Скажем - группой 10 программистов. Считаем что: 1. Что количество программистов адекватно задаче. (+/-) 2. Что пользовательские истории зафиксированы. Чего хочется: Предсказуемость разработки. Оценка состояния проекта, в идеале с шагом в день. Возможность быстро спуститься к самым мелким деталям и оценить их соответствие проектной документации. Ну, проектной документации - громко сказано. Что имеем: Первоначальное описание решения - является неким упражнением для писательского таланта. Ценность теряет ОЧЕНЬ быстро, потому что разработка очень быстро идет в сторону. Зачастую из-за: 1. Пользователи говорят одно, думают другое, а нужно третье. 2. Архитектор перемудрил и решил сделать космолет, который должен рыть бассейны в условиях сверхгравитации и нехватки естественных осадков. 3. Программист неправильно понял, что нужно сделать - и убил три дня на неприменимую ерунду. 4. Программист решил написать свой мега-фреймворк, на который убил 95% времени, результата не достигнув. Вопросы: 1. Каким образом получить исчерпывающее описание проекта, которое не придется выбрасывать в мусорку через месяц? 2. Каким образом технически запретить уходить в сторону? Штуки типа WWF? Быстрые прототипы? Лично я склоняюсь к прототипам. Теперь к коду. Следующая проблема - в системах типа 1С - любой программист имеет доступ к любой части кода. Сам себе архитектор. Когда их 10 человек - уследить за всеми нереально и трешовый код/решения потихоньку берут верх. В .NET/JAVA я представляю что можно сделать - закрыть сборку с моделями и создать нужные интерфейсы, которые потом последовательно реализовывать, но что делать в той же 1С?? В 1С один кодер намутит треш, другой нагородит зауми, пытаясь сделать универсальную приладу, которая нужна всем (никому). Иными словами - какой процесс обеспечит: 1. Разумное количество слоев управления разработкой (истории, требования,UI ,код ) 2. Качество артефактов каждого слоя. Оно должно быть таким, чтобы с каждым низлежащим слоем мог работать специалист, не вовлеченный в этот проект прежде. 3. Каждый артефакт должен быть валидным и не противоречивым! Код понятно - он хотя бы должен работать, а как быть с описанием какого-то процесса?? Как убедиться, что процесс выдает ровно тот результат, который сможет принять на входе следующий процесс? Нужны четкие тиски, но какие тиски у Вордовского документа? Бумага всё стерпит. Нужно качество превратить в количество. Читаю истории, в которых над проектами трудятся люди из разных стран и часовых поясов - как их координировать? Тогда как собственные сотрудники без стояния за спиной сразу же стремятся расползтись в стороны. Как это может выглядеть? 1С case Обычно есть система, которая уже живет несколько лет. Технологии ушли вперед, груз существующих проблем стопорит бизнес-процессы. Все в депрессии. Принято решение переписать всё нафиг на современных технологиях. (Тут всё начинается). Бесконечные совещания, на которых пользователи разных рангов рассказывают о своих фантазиях. Всё, что снилось - всё вываливают. Объяснения куцые, пальцы показывают замысловатые фигуры. Составляется описание нового решения, страниц так на сто. Несмотря на картинки - его никто не читает, и также никто возражений не имеет. Начинается разработка. По грубой оценке - к оценке привлекаются n-программистов. Начинается разработка. Появляются первые результаты. Первые показы. Пользователи в недоумении - нужно же было по другому. Начинаются переделки/доработки, причем каждый программист делает это "втихую", потому как так сказала Лена-менеджер. Ну и в итоге разработка приобретает хаотичный характер. Не думаю, что в случае технологий вида JAVA/.NET картина принципиально другая. Единственно - больше времени нужно потратить на проектирование интерфейсов, но и программист-кодер в сторону не уйдёт. Что НЕ хотелось бы тут обсуждать: 1. UI 2. UX 3. Назначенным со стороны клиента менеджерам - плевать на внедрение. 4. Назначенные со стороны клиента менеджеры - некомпетентны. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 04:19 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
Monochromatique, Правильное ТЗ - это уже половина успеха. Так что начинайте с ТЗ. Ну а кодить по подробному ТЗ - много ума не нужно. Если кто-то с этим не справляется - меняйте, т.к. незаменимых людей нет. Поэтому делайте запас в 20% времени на подобные ситуации и у вас все получится. Читаю истории, в которых над проектами трудятся люди из разных стран и часовых поясов - как их координировать? Тогда как собственные сотрудники без стояния за спиной сразу же стремятся расползтись в стороны. Ну тут проблема либо в исполнителе, либо в ПМ. В любом случае никто кроме вас вам не поможет. У нас есть четкие требования к коду. Если излишне комментируешь - не проблема, значит программист решил что без этого сторонний читатель не поймет кода либо сути задачи по коду. А вот если комментарии отсутствуют, либо тестер не может понять - вам вернут на доработку. Если не уложились в срок (с учетом доработок) - не то что денег не получите, но еще с вас и снимут. Знаете, удар по кошельку чувствуется сильнее чем удар по печени. Так что пользуйте этот подход и эволюция пойдет по указанному вами пути. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 09:55 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
Monochromatique, Вы хотите "серебряную пулю". Ее не существует! А так: 1) Никак. Не надо боятся "выкинуть все в мусор". 2) Никаких "технических" способов не существует. Только "административные", каждое изменение должно быть зафиксировано и для него должно быть зарезервировано время. Никаких "тут делов на 5 минут". А так близко у идеалу это Agile, но тут проблема в самодисциплине команды. Т.е. дисциплина и мотивация должна поддерживаться самой командой. Это сложно, т.к. "ёжик птица гордая, пока не пнешь не полетит" ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 10:00 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
Невозможно контролировать всё и вся в одиночку. Напакостить могут всегда, а вылезет это в самый неподходящий момент. Необходимо разделять между коллегам не только функции, но и ответственность, и улучшать взаимодействие между ними. Если архитектор перемудрил, а программист решил написать свое - зачем Вы наняли архитектора, решениям которого не доверяете, да и каждый программисты у Вас может что угодно, свою систему с нуля написать. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 10:16 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
sereginsereginЕсли архитектор перемудрил, а программист решил написать свое - зачем Вы наняли архитектора, решениям которого не доверяете, да и каждый программисты у Вас может что угодно, свою систему с нуля написать. если архитектор типа перемудрил, а программист не понимая написал свое, то избавьтесь от программиста, который не слушает архитектора. Большое число программистов нужно уже тогда, когда ядро проекта работает в принципе, для облагораживания. Но не на начальном этапе ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 12:47 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
Хочется конкретики. Неужели вы начинаете проектировать на основании 100-страничного вордовского документа с невнятным мычанием? Или вы трансформируете мычание в функциональные требования? Юзеры эти требования читают? Как вы добиваетесь непротиворечивости требований? Сложно объяснить юзеру, что (грубо говоря) видеть ОСВ с немедленным автоматическим обновлением и при этом находясь в форме объекта "поступление товаров" - бред собачачий. Какие артефакты у вас на выходе с каждого уровня? Как вы описываете будущую систему на основнии ФТ? Насколько однозначно? ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 12:49 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
MonochromatiqueХочется конкретики. Неужели вы начинаете проектировать на основании 100-страничного вордовского документа с невнятным мычанием? к примеру, я начинаю проектировать с декомпозиции задачи и разложения какого-то "100-страничного вордовского документа" (правда этой ненужной субстанции обычно нет) на конкретные сервисы. Далее программист реализует эти сервисы в реальности, пусть не так "красочно" как требует релиз, но в работоспособном, хотя бы для проверки архитектуры виде. А уже далее все отдается команде программистов-кодировочников, которые наводят лоск. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 13:01 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
iscrafm когда ядро проекта работает в принципе Кстати, отлично что всплыло "ядро". А что под ним понимается? Конфигуратор типа 1С? Или некий движок предметной области? И как объяснить заказчику, что ему нужно некое "ядро", ведь какого-то результата он не увидит в течении долгого времени - какой тут agile? iscrafm то избавьтесь от программиста, который не слушает архитектора. case - убираем одного, на его месте появляется другой - очень дорогой. Ну или я предъявляю какие-то сверх-требования к программистам, требуя от них явно больше их обычных компетенций. На собеседования приходит ТАКОЕ, что становится обидно за профессию. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 13:03 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
Monochromatique, какая-то у вас не "группа программистов", а непонятное сборище. руководство полностью отсутствует. как программист может делать непонятно что хрен знает сколько времени? он что, "сам по себе, свой собственный"? толпа фрилансеров у вас или одна группа с одной целью? аналитик отсутствует. требования не фиксируются. они выявляются. фиксируется пользовательский поток хотелок. там нет требований. там есть неформализованный набор истерик, обвинений, не имеющих никакого отношения к реальным потребностям фантазий. это работа аналитика _выявлять_ требования. авторПользователи говорят одно, думают другое, а нужно третье. естественно. это данность, с этим нужно работать. они в этом не виноваты, виноваты некомпетентные аналитики, PM'ы, руководители разработки. автор2. Архитектор перемудрил и решил сделать космолет, который должен рыть бассейны в условиях сверхгравитации и нехватки естественных осадков. 3. Программист неправильно понял, что нужно сделать - и убил три дня на неприменимую ерунду. 4. Программист решил написать свой мега-фреймворк, на который убил 95% времени, результата не достигнув. отсутствует руководитель, наняты непонятно кто, отсутствует руководитель, нет абсолютно никакой экспертизы, нет обмена знаний и критики, полная безответственность руководителя. "архитектор" не имеет опыта, не имеет полномочий или не хочет их осуществлять. как программист мог потратить черт знает сколько времени и налабать фреймворк? при том что есть руководитель? при том что есть архитектор? при том что есть сроки у задач? никого из них нет - единственный вывод. автор1. Каким образом получить исчерпывающее описание проекта, которое не придется выбрасывать в мусорку через месяц? это что? "заказчики, дайте мне всё"? а какие такие требования не подвержены изменений? что за глупости и наивняк? автор2. Каким образом технически запретить уходить в сторону? Штуки типа WWF? Быстрые прототипы? Лично я склоняюсь к прототипам. вы скорее всего один из тех "программистов", которые черт знает чем занимаются, у которых виноваты заказчики и пользователи, а они хоте ли бы "полное описание и чтобы оно не менялось", "чтобы сразу сказали что делать и что не делать, а то я же просто программист, а же могу начать делать фреймворк, а задачу могу так и не начать делать" авторСледующая проблема - в системах типа 1С - любой программист имеет доступ к любой части кода. Сам себе архитектор. Когда их 10 человек - уследить за всеми нереально и трешовый код/решения потихоньку берут верх. что за любая часть кода? как это невозможно уследить? вас там на самом деле двое и у каждого своя папочка с копией проекта? автор1. Разумное количество слоев управления разработкой (истории, требования,UI ,код ) 2. Качество артефактов каждого слоя. Оно должно быть таким, чтобы с каждым низлежащим слоем мог работать специалист, не вовлеченный в этот проект прежде. 3. Каждый артефакт должен быть валидным и не противоречивым! Код понятно - он хотя бы должен работать, а как быть с описанием какого-то процесса?? Как убедиться, что процесс выдает ровно тот результат, который сможет принять на входе следующий процесс? Нужны четкие тиски, но какие тиски у Вордовского документа? Бумага всё стерпит. продолжение наивняка человека, не имеющего никакого отношения к организации процессов, к руководству группой. продолжение попыток обвинить всех вокруг, объяснить "им всем", что "они все" сделали неправильно. ведь именно поэтому он сделал то что сделал. потратил время на то, что потратил. а вы не уследили! не предусмотрели! не ввели рамок! не стояли за спиной! дали доступ! верили что я занимаюсь тем чем надо! а пользователи тупые! тз устарело! я узнал об этом когда сказали пользователи! аналитику я ничего не сказал, не сказал руководителю, не сказал архитектору, решил делать фреймворк! в этом во всем виноваты "вы все"! где метрика, позволяющая отследить, что мой процесс идет к тому, чтобы выдать нужный результат? вот! а как я должен по вашему узнать что это так или не так? вот и все! это все вы! Проказница-Мартышка, Осел, Козел да косолапый Мишка затеяли создать ПО... ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 13:05 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
Хвост, залогинься. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 13:16 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
Monochromatiqueiscrafm когда ядро проекта работает в принципе Кстати, отлично что всплыло "ядро". А что под ним понимается? Конфигуратор типа 1С? зачем конфигуратор, если система не требует такого конфигурирования, к примеру. Это основа, которую уже можно расширять вширь, а не в глубину, образно MonochromatiqueНу или я предъявляю какие-то сверх-требования к программистам, требуя от них явно больше их обычных компетенций. разделяй требования к программистам и требования к кодировщикам. Все же это разные люди ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 13:26 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
Monochromatique, Да, пошел поток сознания от вас ... Может нужно начать с того что озвучить свое место в проекте? А то становится все страшнее и страшнее. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 13:27 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
[quote смотрите кого нанимаете]Мутный поток сознания[/смотрите кого нанимаете] Ну, кнопок ты понажимал нормально, но смысла в этом - зеро. Конкретики ноль, и ты знаешь почему. Зачем ты парился - мне непонятно. Объяснишь? ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 13:28 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
Злой БобрМожет нужно начать с того что озвучить свое место в проекте? справедливое замечание. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 13:32 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
Злой БобрMonochromatique, Да, пошел поток сознания от вас ... Может нужно начать с того что озвучить свое место в проекте? А то становится все страшнее и страшнее. А как поменяется ваш мессадж от моего ответа? Вся эта муть типа "ответственность, экспертиза, руководитель" в зубах уже вязнет и практического смысла не несет. ЧЕТЧЕ! Легко работать с классными парнями. Только на всех их не хватит. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 13:35 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
iscrafmЗлой БобрМожет нужно начать с того что озвучить свое место в проекте? справедливое замечание. А что от этого поменяется? Сейчас меня интересует роль PM-а, странно, что это не очевидно. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 13:37 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
Monochromatiqueiscrafmпропущено... справедливое замечание. А что от этого поменяется? Сейчас меня интересует роль PM-а, странно, что это не очевидно. Как от моего места поменяется набор артефактов на неком уровне разработки ПО? ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 13:39 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
Monochromatiqueiscrafmпропущено... справедливое замечание. А что от этого поменяется? Сейчас меня интересует роль PM-а, странно, что это не очевидно. если сантехник спрашивает как организовать коммуникации в многоквартирном доме, то это один уровень представления задачи, если такой же вопрос задается архитектором этого дома, то это другой уровень. Многое меняется, практически все. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 13:46 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
Monochromatiqueiscrafmпропущено... справедливое замечание. А что от этого поменяется? Сейчас меня интересует роль PM-а, странно, что это не очевидно. По вопросам выше очевидно, что интересует роль тимлида, а не РП. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 13:48 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
iscrafmMonochromatiqueпропущено... А что от этого поменяется? Сейчас меня интересует роль PM-а, странно, что это не очевидно. если сантехник спрашивает как организовать коммуникации в многоквартирном доме, то это один уровень представления задачи, если такой же вопрос задается архитектором этого дома, то это другой уровень. Многое меняется, практически все. +1 ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 13:50 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
Monochromatique Считаем что: 2. Что пользовательские истории зафиксированы. ... Чего хочется: Предсказуемость разработки. ... Что имеем: 1. Пользователи говорят одно, думают другое, а нужно третье. Предсказуемость разработки начинается с предсказуемости требований. То, что требования меняются по ходу разработки - это нормально, только процесс их изменения должен быть контролируемый и управляемый. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 13:53 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
iscrafmMonochromatiqueпропущено... А что от этого поменяется? Сейчас меня интересует роль PM-а, странно, что это не очевидно. если сантехник спрашивает как организовать коммуникации в многоквартирном доме, то это один уровень представления задачи, если такой же вопрос задается архитектором этого дома, то это другой уровень. Многое меняется, практически все. Я - отвечаю за проекты в целом и целиком. Со спецификой, свойственной конкретной организации, она есть везде. Я ответил на вопрос? ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 13:53 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
Monochromatiqueiscrafmпропущено... если сантехник спрашивает как организовать коммуникации в многоквартирном доме, то это один уровень представления задачи, если такой же вопрос задается архитектором этого дома, то это другой уровень. Многое меняется, практически все. Я - отвечаю за проекты в целом и целиком. Со спецификой, свойственной конкретной организации, она есть везде. Я ответил на вопрос? да, вполне ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 13:56 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
JE SUIS ЦКтолько процесс их изменения должен быть контролируемый и управляемый. Опять вода. Парни, ну вы понимаете что ценности в этих словах - НОЛЬ. Ну что, кто-то скажет, что процесс изменений должен быть неуправляемый?? Чего вы воду толчете? ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 13:57 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
MonochromatiqueJE SUIS ЦКтолько процесс их изменения должен быть контролируемый и управляемый. Опять вода. Парни, ну вы понимаете что ценности в этих словах - НОЛЬ. Ну что, кто-то скажет, что процесс изменений должен быть неуправляемый?? Чего вы воду толчете? Это вы вопросы задаете "что делать?", а не я. В вашем описании ситуации требования неуправляемые. Что вы с этим собираетесь конкретно делать? ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 14:02 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
Monochromatiqueiscrafmпропущено... если сантехник спрашивает как организовать коммуникации в многоквартирном доме, то это один уровень представления задачи, если такой же вопрос задается архитектором этого дома, то это другой уровень. Многое меняется, практически все. Я - отвечаю за проекты в целом и целиком. Со спецификой, свойственной конкретной организации, она есть везде. Я ответил на вопрос? а смысл настаивать на этом? по текстам - больше похоже на то что рядом сидят "взрослые дядьки", от них краем уха ловятся хитрые слова, далее с учетом возраста и образования пытаемся собрать слова в осмысленные предложения. получается не очень, что видно более чем одному участнику. если не это (сильно сомневаюсь что это не случай синдрома "если бы я был моим папой...") и должность реально пмовская (что на самом деле тоже абсолютно реально, т.к. пихают туда не пойми кого чуть не с 19 лет отроду непрерывно), то первое что можно рекомендовать работодателю - смотреть кого нанимаете. по факту с такой квалификацией может оказаться и 40-летний дерктор проектного офиса в нехилой по размерам конторе, но 18455158 и 18455129 как бы намекают что и возраст, и положние ровно те, на который они намекают. нет, я не с твоей работы, в понедельник носом тыкать в показуху не смогу. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 14:05 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
MonochromatiqueЯ - отвечаю за проекты в целом и целиком. Со спецификой, свойственной конкретной организации, она есть везде. Ну тогда вам по обязанностям и положено "страдать". Что собственно должно компенсироваться деньгами. Насчет того что "Легко работать с классными парнями. Только на всех их не хватит.". Ответ только один - переманивайте. Думаю что 30% и выше, от того что они имеют, могут подавляющее большинство адекватных людей заставить задуматься над вашим предложением. Не говорю за всех, т.к. есть контингент который и за 200% не дернется с насиженного места. Но большинство будут готовы всерьез рассматривать такие предложения. Все в ваших руках. И да, если не готовы переманивать - продолжайте страдать. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 14:10 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
JE SUIS ЦК Что вы с этим собираетесь конкретно делать? Задаю вопрос на этом форуме. Как добиваются понимания, что разработка идёт в правильном направлении. С шагом в один день. У меня были разные сотрудники. Одному можно было сказать задачу в общем - и он выдавал конфету (в моменте). В целом у него получались переусложненные системы. За другим - надо было следить каждый три часа - вечно куда-то уходил в сторону. Третий вообще ни о чем, но пользователи его обожали, потому что он делал любые залипухи по их требованиям. Правда программа потом требовала постоянного обслуживания, но никто не думал, что это как-то неправильно. Но юзеры были довольны, так как их никто думать не заставлял. Четвертый снюхался с руководством, и ушел в отдельную ветку проекта. Которую с успехом завалил. Историй много, есть цветные, есть никакие. Это всё в контексте 1С. В случае с "взрослыми" технологиями, мне кажется, что я знаю, что делать. Я повторю свой вопрос сжато: 1. На какие этапы участники форума бьют задачи. Задачи уровня "10 человек - полгода". 2. Какие артефакты выдает каждый этап? В каком виде? 3. Кто и как решает, что артефакт валидный. Ну то есть не - "я почитал, вроде нормально". ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 14:13 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
Monochromatique1. Каким образом получить исчерпывающее описание проекта, которое не придется выбрасывать в мусорку через месяц? Дать задание архитектору подготовить исчерпывающее описание проекта Monochromatique2. Каким образом технически запретить уходить в сторону? Дать задание архитектору контролировать эти вопросы MonochromatiqueПользователи в недоумении - нужно же было по другому. попробуйте вместо сантехника найти архитектора который сделает машину для покраски на запрос пользователей вместо машины для поливания клумбы это же типичная ситуация ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 14:14 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
Злой БобрMonochromatiqueЯ - отвечаю за проекты в целом и целиком. Со спецификой, свойственной конкретной организации, она есть везде. Ну тогда вам по обязанностям и положено "страдать". Не-не, что за подход. Нету такой должности - страдальца. Верю, что разработку можно превратить в конвейер. С минимальным процентом "творчества" и неопределённости. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 14:17 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
смотрите кого нанимаете Я тебя как-то обидел? Один из моих проектов выложен на этом форуме в виде презентации, ты его (этот пост) видел. Считаю, что он выполнен на достойном уровне - и это уровень - мой, вне зависимости от того, устраивает тебя это или нет. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 14:20 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
iscrafmДать задание архитектору подготовить исчерпывающее описание проекта Отлично. Просто отлично. Как понять, что он справился с задачей? Если программист написал плохой запрос/функцию - её можно переписать. Если архитектор неправильно описал проект и!! если понять это поздно - то это выливается в гораздо большие проблемы. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 14:23 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
MonochromatiqueiscrafmДать задание архитектору подготовить исчерпывающее описание проекта Отлично. Просто отлично. Как понять, что он справился с задачей? послушать его доклад образно. ты мне напоминаешь директора завода который штанкгенциркулем допуски за рабочим проверяет ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 14:29 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
судя по всему программиста сделали РП перепрыгнув через голову того же архитектора? ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 14:30 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
iscrafmДать задание архитектору подготовить исчерпывающее описание проекта И еще такая проблема. Если описывать проект в ворде (текст), то нет никаких сдерживающих факторов, что к 50-той странице проект не начнет отрицать сам себя. Такой вот выверт. Только на 50-ой странице это будет непонятно. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 14:30 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
MonochromatiqueiscrafmДать задание архитектору подготовить исчерпывающее описание проекта И еще такая проблема. Если описывать проект в ворде (текст), то нет никаких сдерживающих факторов, что к 50-той странице проект не начнет отрицать сам себя. Такой вот выверт. нужен просто нормальный архитектор, а не ярлык архитектора ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 14:32 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
iscrafmты мне напоминаешь директора завода который штанкгенциркулем допуски за рабочим проверяет Когда ракета вдруг разваливается в воздухе - каждый о чем то призадумывается. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 14:33 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
iscrafmMonochromatiqueпропущено... И еще такая проблема. Если описывать проект в ворде (текст), то нет никаких сдерживающих факторов, что к 50-той странице проект не начнет отрицать сам себя. Такой вот выверт. нужен просто нормальный архитектор, а не ярлык архитектора Не вопрос. Как отличить нормального от ярлыка? ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 14:34 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
Monochromatiqueiscrafmты мне напоминаешь директора завода который штанкгенциркулем допуски за рабочим проверяет Когда ракета вдруг разваливается в воздухе - каждый о чем то призадумывается. iscrafmнужен просто нормальный архитектор, а не ярлык архитектора ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 14:34 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
MonochromatiqueJE SUIS ЦК Что вы с этим собираетесь конкретно делать? Задаю вопрос на этом форуме. И зачем, если вы даже не желаете слушать даваемые ответы? MonochromatiqueКак добиваются понимания, что разработка идёт в правильном направлении. С шагом в один день. Совершенно очевидный ответ - сначала выяснить, что же это такое "правильное направление". То есть определить требования к ИС + установить управляемый процесс изменения этих требований. Иначе ваше "правильное направление" будет болтаться как флюгер на ветру каждый день. Насколько я понял ответы выше, вы с этим делать ничего не будете. Результат будет немного предсказуем. MonochromatiqueУ меня были разные сотрудники. Они всегда разные. MonochromatiqueВ случае с "взрослыми" технологиями, мне кажется, что я знаю, что делать. Я повторю свой вопрос сжато: 1. На какие этапы участники форума бьют задачи. Задачи уровня "10 человек - полгода". Это не уровень. Это объем примерно в тысячу человекодней, причем непонятно кем и как оцененный. Monochromatique2. Какие артефакты выдает каждый этап? В каком виде? В каком договорились при определении процесса разработки. Или документы вордового формата, или схемы/диаграммы в повердизайнере (или аналогичном инстурменте) или списки в инструментах управления процессом типа HPALM. Тут нет универсального решения в принципе. Monochromatique3. Кто и как решает, что артефакт валидный. Ну то есть не - "я почитал, вроде нормально". Кто согласует тот или иной документ. Это опять вопрос к процессу. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 14:37 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
У меня такое впечатление, что требования к РП, архитектору простые - быть душой компании и уметь играть на гитаре "отель Калифорния". А если ты хороший парень, что значит и то,что ты делаешь - хорошо. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 14:37 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
iscrafmMonochromatiqueпропущено... И еще такая проблема. Если описывать проект в ворде (текст), то нет никаких сдерживающих факторов, что к 50-той странице проект не начнет отрицать сам себя. Такой вот выверт. нужен просто нормальный архитектор, а не ярлык архитектора Как за полчаса на собеседовании понять, что перед вами хорший архитектор или PM? ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 14:39 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
MonochromatiqueВерю, что разработку можно превратить в конвейер. С минимальным процентом "творчества" и неопределённости. Да. И таджиков подешевле поставить - чего там делать-то, конвеер же ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 14:39 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
MonochromatiqueiscrafmДать задание архитектору подготовить исчерпывающее описание проекта Отлично. Просто отлично. Как понять, что он справился с задачей? Если программист написал плохой запрос/функцию - её можно переписать. Если архитектор неправильно описал проект и!! если понять это поздно - то это выливается в гораздо большие проблемы. Это исключительно к вам вопрос - откуда вы взяли архитектора, как отбирали, как нанимали. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 14:40 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
Monochromatiqueiscrafmпропущено... нужен просто нормальный архитектор, а не ярлык архитектора Как за полчаса на собеседовании понять, что перед вами хорший архитектор или PM? за полчаса на собеседовании можно нанять разве что кодировщика, но не архитектора. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 14:41 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
Monochromatiqueiscrafmпропущено... нужен просто нормальный архитектор, а не ярлык архитектора Как за полчаса на собеседовании понять, что перед вами хорший архитектор или PM? для этого нужно самому хоть в чем-то из перечисленного разбираться ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 14:41 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
смотрите кого нанимаетеMonochromatiqueпропущено... Как за полчаса на собеседовании понять, что перед вами хорший архитектор или PM? для этого нужно самому хоть в чем-то из перечисленного разбираться естественно. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 14:42 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
iscrafmсудя по всему программиста сделали РП перепрыгнув через голову того же архитектора? Да РП сейчас назначают кого ни попадя. Что ведет к полной деградации понимания этой профессии - точно так же, как в свое время деградировали понятие "менеджер" и после этого появились кадавры типа "офис-менеджер" или "менеджер по уборке помещений". Хотя изначально в англоязычной литературе, скажем, General Manager примерно соответствует члену Правления в российской терминологии. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 14:44 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
MonochromatiqueУ меня такое впечатление, что требования к РП, архитектору простые - быть душой компании и уметь играть на гитаре "отель Калифорния". А если ты хороший парень, что значит и то,что ты делаешь - хорошо. Такого я еще не встречал. Плакать или смеяться - еще не решил... ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 14:46 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
[quot JE SUIS ЦК]Monochromatiqueпропущено... Задаю вопрос на этом форуме. авторИ зачем, если вы даже не желаете слушать даваемые ответы? Если вы имеете в виду себя, то я не понимаю ваших ответов. Какие-то советские агитки - "мы все как один и недалек тот час". авторНасколько я понял ответы выше, вы с этим делать ничего не будете. Вы неправильно поняли. авторЭто не уровень. Это объем примерно в тысячу человекодней, причем непонятно кем и как оцененный. Ну как-то я должен с вами изъяснятся. авторВ каком договорились при определении процесса разработки. Вы будете писать код на JAVA в блокноте? Если вы договорились? Нет? А почему? ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 14:46 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
Monochromatiqueiscrafmпропущено... нужен просто нормальный архитектор, а не ярлык архитектора Как за полчаса на собеседовании понять, что перед вами хорший архитектор или PM? А какие вопросы вы задаете за эти полчаса? Хорошо ли на гитаре Хотэл Калифорния играете??? ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 14:46 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
смотрите кого нанимаетеMonochromatiqueпропущено... Как за полчаса на собеседовании понять, что перед вами хорший архитектор или PM? для этого нужно самому хоть в чем-то из перечисленного разбираться Или привлечь заслуживающего доверия специалиста, который вам в этом поможет. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 14:47 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
JE SUIS ЦКMonochromatiqueУ меня такое впечатление, что требования к РП, архитектору простые - быть душой компании и уметь играть на гитаре "отель Калифорния". А если ты хороший парень, что значит и то,что ты делаешь - хорошо. Такого я еще не встречал. Что значит не встречал - это ты чуть ли не постулируешь. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 14:48 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
JE SUIS ЦКА какие вопросы вы задаете за эти полчаса? Да блин - я НЕ ЗНАЮ. На программистов у меня есть ряд вопросов, заламинированных цветных бумажек. Какие качества должен изобразить архитектор в сжатое время - я НЕ ЗНАЮ. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 14:51 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
MonochromatiqueЕсли вы имеете в виду себя, то я не понимаю ваших ответов. Когда-нибудь поймете, не все сразу... MonochromatiqueКакие-то советские агитки - "мы все как один и недалек тот час". Облепить ярлыками то, что не понимаете - верх гениальности. MonochromatiqueВы будете писать код на JAVA в блокноте? Если вы договорились? Нет? А почему? Когда Java только начиналась в конце 90-х, некоторые из моих приятелей код для нее писали в Far-е. С плагином для него, который код подсвечивал. Это практически тот самый блокнот. Удобные инструменты типа IntelliJ IDEA и прочие джетбрейны появились позже. Так что и такой вариант не исключен - опять возвращаемся к процессам и их зрелости. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 14:56 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
JE SUIS ЦКMonochromatiqueЕсли вы имеете в виду себя, то я не понимаю ваших ответов. Когда-нибудь поймете, не все сразу... Так может и понимать нечего? Какую методологию ведения проектов конкретно ВЫ применяете и какие инструменты конкретно ВЫ используете. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 15:00 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
MonochromatiqueJE SUIS ЦКА какие вопросы вы задаете за эти полчаса? Да блин - я НЕ ЗНАЮ. На программистов у меня есть ряд вопросов, заламинированных цветных бумажек. Какие качества должен изобразить архитектор в сжатое время - я НЕ ЗНАЮ. 1. Нахрена сжимать время на собеседованиях? Это самая тупая экономия, которую только можно придумать. Потратье 1,5-2 часа времени вместо получаса. Если вы наняли некомпетентного спеца, то потом вам же придется потратить значительно больше времени и сил, чтобы от него избавиться. Ваш фильтр на собеседованиях должен максимально эффективно работать. 2. Очевидно, вы не знаете требований к архитектору. Может с этого и стоит начать? ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 15:00 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
JE SUIS ЦК Очевидно, вы не знаете требований к архитектору. Может с этого и стоит начать? Может. Я говорил что то другое? Впрочем, можно ответить в вашем стиле - хороший архитектор должен выдать хорошую архитектуру. Чем не требование? ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 15:02 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
MonochromatiqueТак может и понимать нечего? Может, и нечего. Тогда какой смысл мне тратить свое время на очередного гения от управления, который свято верит в конвеер разработки и сам не знает нафига ему сдался архитектор? А промышленные технологии ему помогут и все проблемы решат, не придется заниматься мутью с становлением и совершенствованием процессов. Это все советские агитки, ну далее там по тексту... ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 15:04 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
MonochromatiqueJE SUIS ЦК Очевидно, вы не знаете требований к архитектору. Может с этого и стоит начать? Может. Я говорил что то другое? Впрочем, можно ответить в вашем стиле - хороший архитектор должен выдать хорошую архитектуру. Чем не требование? Отлично. Осталось научиться отличать хорошую архитектуру от не очень. Еще 100500 итераций и до тогафа так дойдем... ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 15:06 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
JE SUIS ЦКНахрена сжимать время на собеседованиях? Это самая тупая экономия Затем, что: 1. Каждый второй в своих скиллах заявляет что он "директор/архитектор/PM" 2. Рабочий день - восемь часов. Если на фильтр агнцев от козлищ тратить по два часа, то кто-то должен этим заниматься постоянно. Для меня это - не основной процесс. Конкретно ВЫ сами себе противоречите на второй же странице этой темы. Если сейчас у вас уже сложности, то как вы управляете проектами, ну, кроме как "а кому заварить чайку?" ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 15:07 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
JE SUIS ЦК и до тогафа так дойдем... Ого. Уже и TOGAF появился. Я чего было сразу с него не начать? ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 15:08 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
MonochromatiqueКакую методологию ведения проектов конкретно ВЫ применяете и какие инструменты конкретно ВЫ используете. В разных случаях - разную. По одному направлению - чистый водопад. По другому Agile с элементами scrum, дополненный классическим планированием. Инструменты разработки - те, которые вендоры поставляют, другие вы там использовать не сможете. В качестве инструментов сбора требований - помесь word-а и HPALM, и этот набор меня не особо устраивает, есть идеи как сделать лучше. Но любая методология панацеей не является, даже PMI оговорку делает - методы скорее всего будут работать в большинстве случаев, но гарантий они не дают. И именно поэтому никогда не будет конвеера. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 15:12 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
MonochromatiqueJE SUIS ЦК и до тогафа так дойдем... Ого. Уже и TOGAF появился. Я чего было сразу с него не начать? В школе сначала на палочках считать учат. Потом арифметику. Потом уравнения разных степеней. Потом производные с интегралами. Можно, конечно, с интегралов начать, но тогда в обратку получаешь вопли про то, что это много воды и непонятные закорючки с агитками из советских времен. Арифметику освойте сначала, вам про это уже выше неоднократно писали (требования, подбор людей, etc...). ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 15:16 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
MonochromatiqueJE SUIS ЦКНахрена сжимать время на собеседованиях? Это самая тупая экономия Затем, что: 1. Каждый второй в своих скиллах заявляет что он "директор/архитектор/PM" 2. Рабочий день - восемь часов. Если на фильтр агнцев от козлищ тратить по два часа, то кто-то должен этим заниматься постоянно. Для меня это - не основной процесс. Когда-нибудь вы поймете, что подбор людей, с которыми вам дальше работать - это самый основной процесс, основнее не бывает. Если вас раньше из управленцев не выпнут, с таким отношением обычно долго протянуть не удается... MonochromatiqueКонкретно ВЫ сами себе противоречите на второй же странице этой темы. Если сейчас у вас уже сложности, то как вы управляете проектами, ну, кроме как "а кому заварить чайку?" Сложности у вас, дружище. Вам тут в меру сил пытаются помочь советами, но альтруизм не беспределен. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 15:20 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
MonochromatiqueВерю, что разработку можно превратить в конвейер. Какая наивность. MonochromatiqueКак за полчаса на собеседовании понять, что перед вами хорший архитектор или PM? Никак. Те кто ставит перед собой такую задачу уже обречены. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 15:21 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
JE SUIS ЦККогда-нибудь вы поймете, что подбор людей, с которыми вам дальше работать - это самый основной процесс, основнее не бывает. Если вас раньше из управленцев не выпнут, с таким отношением обычно долго протянуть не удается... Мой опыт говорит о другом. На этом закончим. Спорить с экзальтированным менеджером нет желания. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 15:25 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
Злой БобрMonochromatiqueВерю, что разработку можно превратить в конвейер. Какая наивность. Эммммм... Спасибо за оценку, конечно. В каждой технарской профессии есть те, кто хочет считать себя художником (без рамок и обязательств), но и ЗП получать регулярно - вот тут нам конвейрер па-да-вай. MonochromatiqueКак за полчаса на собеседовании понять, что перед вами хорший архитектор или PM? Никак. Те кто ставит перед собой такую задачу уже обречены. Ок, никак. Каков тогда кейс? ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 15:28 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
MonochromatiqueJE SUIS ЦККогда-нибудь вы поймете, что подбор людей, с которыми вам дальше работать - это самый основной процесс, основнее не бывает. Если вас раньше из управленцев не выпнут, с таким отношением обычно долго протянуть не удается... Мой опыт говорит о другом. На этом закончим. Спорить с экзальтированным менеджером нет желания. как раз все говорит обратном, у тебя риторика и понимание процесса глазами "экзальтированого менеджера" или программера. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 15:32 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
Злой БобрMonochromatiqueКак за полчаса на собеседовании понять, что перед вами хорший архитектор или PM? Никак. Те кто ставит перед собой такую задачу уже обречены. Пусть ставят. Они таким образом создают фронт работ - после того, как их попрут, придем мы и будем исправлять то, что до нас конвеерные гении науправляли. За большие деньги, конечно - менять кривые процессы и демотивированные команды заметно сложнее, чем с нуля строить/собирать. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 15:32 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
MonochromatiqueJE SUIS ЦККогда-нибудь вы поймете, что подбор людей, с которыми вам дальше работать - это самый основной процесс, основнее не бывает. Если вас раньше из управленцев не выпнут, с таким отношением обычно долго протянуть не удается... Мой опыт говорит о другом. На этом закончим. Спорить с экзальтированным менеджером нет желания. (дубль 2) Зачем вам что-то отвечать, если вы не собираетесь это слушать? Стройте свой конвеер, нам потом о невероятных успехах на этом поприще расскажете.... ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 15:37 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
MonochromatiqueОк, никак. Каков тогда кейс? Идите самым простым путем - переманивайте. Выше я уже писал вам об этом. Зачем пытаться делать то чего неумеешь? Наймите специалистов своего дела. И да, им придется хорошо платить. Я не исключаю что есть хорошие специалисты которые "кодят за еду", но практика показывает что вероятность найти такого ничтожно мала. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 15:38 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
iscrafmMonochromatiqueпропущено... Мой опыт говорит о другом. На этом закончим. Спорить с экзальтированным менеджером нет желания. как раз все говорит обратном, у тебя риторика и понимание процесса глазами "экзальтированого менеджера" или программера. Так менеджера или программера? ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 15:39 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
Злой БобрMonochromatiqueОк, никак. Каков тогда кейс? Идите самым простым путем - переманивайте. Выше я уже писал вам об этом. Зачем пытаться делать то чего неумеешь? Наймите специалистов своего дела. И да, им придется хорошо платить. Я не исключаю что есть хорошие специалисты которые "кодят за еду", но практика показывает что вероятность найти такого ничтожно мала. Ну, то есть - опираться исключительно на репутацию - я правильно понял? ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 15:41 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
Злой БобрMonochromatiqueОк, никак. Каков тогда кейс? Идите самым простым путем - переманивайте. Выше я уже писал вам об этом. Зачем пытаться делать то чего неумеешь? Наймите специалистов своего дела. И да, им придется хорошо платить. Я не исключаю что есть хорошие специалисты которые "кодят за еду", но практика показывает что вероятность найти такого ничтожно мала. Он их определять не умеет. Что означает, что если даже на таких людей есть бюджет (+30+50% к рынку), то не факт, что тот, кого наймут, будет именно тем "специалистом своего дела". А не тем, кто за полчаса себя красиво продал на собеседовании... ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 15:42 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
Ребят, вы попуститесь.))))) Я не уверен, что вы сумеете ответить на прогерские вопросы, с вашим-то гонором. Что уж говорить об архитектурных задатках\качествах, когда как даже эту тему с простыми вопросами умудрились превратить в помойку. Как вы собираетесь проходить на архитектора, с одним критерием - "она хорошая"? Большего от вас не добиться. Одна правда - на собеседовании я бы долго слушать эту муть не стал, дал бы задание на дом, из вежливости конечно, и иди к следующему. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 15:50 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
MonochromatiqueНу, то есть - опираться исключительно на репутацию - я правильно понял? Да. Параллельно нанимайте студентов, которые через 3-5 лет смогут вырасти до необходимого уровня. Опять же бестолковые сами со временем отсеются. Но тут учитывайте факт что некоторые специалисты по своему складу не готовы передавать опыт и готовить зеленых необстреляных студентов. Так что внимательно подходите к этому моменту, дабы не сделать работу специалиста "некомфортной". ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 15:50 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
Monochromatiqueiscrafmпропущено... как раз все говорит обратном, у тебя риторика и понимание процесса глазами "экзальтированого менеджера" или программера. Так менеджера или программера? или Ну хоть это же нужно знать, хоть основы языка. Или к чему вопрос? ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 15:51 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
Злой БобрMonochromatiqueНу, то есть - опираться исключительно на репутацию - я правильно понял? Да. Параллельно нанимайте студентов, которые через 3-5 лет смогут вырасти до необходимого уровня. Опять же бестолковые сами со временем отсеются. Студенты?? Вырасти за три-пять лет?? Любезный Злой Бобр, я не ГЭС строю. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 15:52 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
MonochromatiqueРебят, вы попуститесь.))))) Я не уверен, что вы сумеете ответить на прогерские вопросы, с вашим-то гонором. Что уж говорить об архитектурных задатках\качествах, когда как даже эту тему с простыми вопросами умудрились превратить в помойку. Как вы собираетесь проходить на архитектора, с одним критерием - "она хорошая"? Большего от вас не добиться. Одна правда - на собеседовании я бы долго слушать эту муть не стал, дал бы задание на дом, из вежливости конечно, и иди к следующему. ты бы самомнение не выпячивал, задавая откровенно глупые вопросы. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 15:53 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
iscrafmMonochromatiqueРебят, вы попуститесь.))))) Я не уверен, что вы сумеете ответить на прогерские вопросы, с вашим-то гонором. Что уж говорить об архитектурных задатках\качествах, когда как даже эту тему с простыми вопросами умудрились превратить в помойку. Как вы собираетесь проходить на архитектора, с одним критерием - "она хорошая"? Большего от вас не добиться. Одна правда - на собеседовании я бы долго слушать эту муть не стал, дал бы задание на дом, из вежливости конечно, и иди к следующему. ты бы самомнение не выпячивал, задавая откровенно глупые вопросы. А по делу будет что-нибудь? Для програмера или менеджера или собственника или... Тут по вкусу. Тыкни хоть один глупый вопрос. Давай - ОДИН. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 15:56 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
MonochromatiqueОдна правда - на собеседовании я бы долго слушать эту муть не стал, дал бы задание на дом, из вежливости конечно, и иди к следующему. правда как раз в том, что нормальный специалист к тебе бы не пошел на собеседование изначально или ушел бы, услышав начало собеседования. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 15:56 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
Злой БобрДа. Параллельно нанимайте студентов, которые через 3-5 лет смогут вырасти до необходимого уровня. Опять же бестолковые сами со временем отсеются. Вы бюджет подобных затей себе представляте? ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 15:57 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
MonochromatiqueТыкни хоть один глупый вопрос. Давай - ОДИН MonochromatiqueВопросы: 1. Каким образом получить исчерпывающее описание проекта, которое не придется выбрасывать в мусорку через месяц? 2. Каким образом технически запретить уходить в сторону? Штуки типа WWF? Быстрые прототипы? Лично я склоняюсь к прототипам. в начальном посте, вообще-то ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 15:57 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
iscrafmMonochromatiqueОдна правда - на собеседовании я бы долго слушать эту муть не стал, дал бы задание на дом, из вежливости конечно, и иди к следующему. правда как раз в том, что нормальный специалист к тебе бы не пошел на собеседование изначально или ушел бы, услышав начало собеседования. Несешь ахинею. Ты там не был, но выводы делаешь. Тебя это не красит, учитывая даже то, что ты знаешь где прочитать про "или" ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 15:58 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
iscrafmMonochromatiqueТыкни хоть один глупый вопрос. Давай - ОДИН MonochromatiqueВопросы: 1. Каким образом получить исчерпывающее описание проекта, которое не придется выбрасывать в мусорку через месяц? 2. Каким образом технически запретить уходить в сторону? Штуки типа WWF? Быстрые прототипы? Лично я склоняюсь к прототипам. в начальном посте, вообще-то Ну и в чем глупость-то?? В контексте 1С. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 15:59 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
MonochromatiqueСтуденты?? Вырасти за три-пять лет?? Любезный Злой Бобр, я не ГЭС строю. Ну если вы не готовы развиваться, можете и дальше жить "одним днем". Опять же найти нормального архитектора "на проект" - это фантастика. Как правило архитектор держит одновременно от 3-х до 8-ми проектов. Тогда и результат соответствует. А с вашим подходом только и остается: Я - отвечаю за проекты в целом и целиком. Только учтите что незаменимых людей нет. Надоест владельцу бизнеса и он быстро вас избавит от "страданий". Что думаю будет правильным решением. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 16:01 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
Злой БобрКак правило архитектор держит одновременно от 3-х до 8-ми проектов. Тогда и результат соответствует. O_O Это что за проекты-то? Сайты-визитки?? ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 16:02 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
Monochromatiqueiscrafmпропущено... пропущено... в начальном посте, вообще-то Ну и в чем глупость-то?? В контексте 1С. АААААААА!!! ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 16:03 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
Monochromatiqueiscrafmпропущено... правда как раз в том, что нормальный специалист к тебе бы не пошел на собеседование изначально или ушел бы, услышав начало собеседования. Несешь ахинею. Ты там не был, но выводы делаешь. Тебя это не красит, учитывая даже то, что ты знаешь где прочитать про "или" вообще-то я подобных систем сделал больше одной даже, да и проектов много. Поэтому сразу видно "экзальтированного менеджера" или программера, на которого внезапно свалился груз управления каким-то проектом по созданию ПО. Так что ахинею скорее ты несешь. Хотя я сказал точнее: выпячивая самомнение хочешь узнать о работе которая на тебя свалилась вместо внимания советам и мнениям. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 16:04 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
Злой БобрНу если вы не готовы развиваться, можете и дальше жить "одним днем". Я правильно понимаю, что это мне говорит "Программист 1С77"? ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 16:05 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
Monochromatiqueiscrafmпропущено... пропущено... в начальном посте, вообще-то Ну и в чем глупость-то?? В контексте 1С. примерно как строитель спрашивает о том как кладку ложить, а архитектор о том, как определить солнечную сторону у здания. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 16:08 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 16:11 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
iscrafmMonochromatiqueпропущено... Ну и в чем глупость-то?? В контексте 1С. примерно как строитель спрашивает о том как кладку ложить, а архитектор о том, как определить солнечную сторону у здания. Да, но ответов я не получил. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 16:18 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
MonochromatiqueЗлой БобрНу если вы не готовы развиваться, можете и дальше жить "одним днем". Я правильно понимаю, что это мне говорит "Программист 1С77"? Да, вы поняли абсолютно верно. Я действительно знаю только 7.7. И "снеговика" даже не пытался изучать, т.к. это такое же кривое решение как и 7.7, но уже за совсем другие деньги. Да и последние несколько лет работаю на американскую ИТ компанию, где и не слышали о том что есть такая "замечательная" система как 1С (вот глупые американцы, и как же они без 1С бизнес делают ...). Но зато есть база в мелкомягком скуле и приложение (собственно писалось работниками компании). И много чего еще. Но самое что бросается в глаза, так это подход. У нас все побыстрячку и навскидку, а там все по плану на 10+ дней. Вот же ж действительно люди "работать" неумеют. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 16:20 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
iscrafmвнезапно свалился груз управления каким-то проектом по созданию ПО. iscrafmMonochromatiqueпропущено... Несешь ахинею. Ты там не был, но выводы делаешь. Тебя это не красит, учитывая даже то, что ты знаешь где прочитать про "или" вообще-то я подобных систем сделал больше одной даже, да и проектов много. Поэтому сразу видно "экзальтированного менеджера" или программера, на которого внезапно свалился груз управления каким-то проектом по созданию ПО. Так что ахинею скорее ты несешь. Хотя я сказал точнее: выпячивая самомнение хочешь узнать о работе которая на тебя свалилась вместо внимания советам и мнениям. Ой бл*.... 2006-2008 Разработка клиентского ПО (кассового места) для ресторанов. Серьезная доработка бекенда. Основные пользователи находятся за 3000 км. 2008-2010 год Разработка и внедрение решения для оптово-дистрибьюторского холдинга. Внедрение в три организации. До сих пор на нём работают. 1С 8.1 Оборот - 2000 складских документов в день в одной базе. 2009 год. Разработка мобильного клиента. Windows Mobile 6.5 2012 год. Разработка мобильного клиента. Windows Phone 7\8 2013 год. Разработка решения для транспортной компании. Коммерция\Финансы\Операцинка\Отслеживание\Интеграция внешних сервисов\Расчет маршрутов. 2014-15. Перевод розничной сети (150 магазинов) с 1С УРИБ на Web Service-ы, с переносом функционала из локального решения в центральное. Это из крупного. О чем вообще заикаться стоит. Мы решили вопрос со "внезапно свалился груз", iscrafm? ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 16:21 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
Злой БобрДа, вы поняли абсолютно верно. Я действительно знаю только 7.7. Тогда расскажешь, как восстановить партионный учет с количеством складских документов 2000 в день за полчаса не прерывая работы пользователей и не мешая им? Предметная область вроде обязываает понимать - о чем речь? Ну, как архитектор архитектору, по свойски? Это один из вопросов на собеседовании, если чо))))) P.S. Ничего, что я на ты? Риторика "экзальтированного менеджера или программера" происходящей полемики как-то не предполагает расшаркиваний. )))) ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 16:27 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
Monochromatiqueiscrafmвнезапно свалился груз управления каким-то проектом по созданию ПО. iscrafmпропущено... вообще-то я подобных систем сделал больше одной даже, да и проектов много. Поэтому сразу видно "экзальтированного менеджера" или программера, на которого внезапно свалился груз управления каким-то проектом по созданию ПО. Так что ахинею скорее ты несешь. Хотя я сказал точнее: выпячивая самомнение хочешь узнать о работе которая на тебя свалилась вместо внимания советам и мнениям. Ой бл*.... 2006-2008 Разработка клиентского ПО (кассового места) для ресторанов. Серьезная доработка бекенда. Основные пользователи находятся за 3000 км. 2008-2010 год Разработка и внедрение решения для оптово-дистрибьюторского холдинга. Внедрение в три организации. До сих пор на нём работают. 1С 8.1 Оборот - 2000 складских документов в день в одной базе. 2009 год. Разработка мобильного клиента. Windows Mobile 6.5 2012 год. Разработка мобильного клиента. Windows Phone 7\8 2013 год. Разработка решения для транспортной компании. Коммерция\Финансы\Операцинка\Отслеживание\Интеграция внешних сервисов\Расчет маршрутов. 2014-15. Перевод розничной сети (150 магазинов) с 1С УРИБ на Web Service-ы, с переносом функционала из локального решения в центральное. Это из крупного. О чем вообще заикаться стоит. Мы решили вопрос со "внезапно свалился груз", iscrafm? понятно, т.е. ничего серьезного не делал, типа только внедрения 1С. Только ценность проекта оцениваешь типично программерскими критериями, типа "2000 складских документов в день в одной базе" или "150 магазинов".... Почему тогда взявшись за действительно проект по созданию системы игнорируете так советы? ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 16:44 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
MonochromatiqueТогда расскажешь, как восстановить партионный учет с количеством складских документов 2000 в день за полчаса не прерывая работы пользователей и не мешая им? элементарно: организовать параллельный ввод, а в основном сделать партионный учет, и добавить затем введенные новые документы. Задача простая и количество документов здесь конечно-же не при чем ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 16:48 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
Monochromatique, Количество документов не является показателем. У вас может быть в документе 3-5 записей, а может и 500+. Это к пониманию о "количестве документов в день". И при больших объемах я вообще не стал бы вести партионный учет в том виде в котором он есть в типовых конфигурациях. Большие обемы по моим меркам 10к+ документов в день с количеством записей 100+ . И да, это на 7.7 и это не фантастика. Да, я могу вам рассказать и показать как это сделать. Могу также показать как на УРБД сделать миграцию по типу звезды и пр. Ну и много чего могу. Но за деньги. Если вы считаете себя архитектором, то я не считаю. Более того для 1С не может быть понятия архитектор. Если есть человек с опытом от 5-7 лет, то он сможет все сделать. По крайней мере я не встречал ни одного живого архитектора 1С. Хотя это может как с сусликом, его никто не видит но он есть. Да, можно на "ты". ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 16:51 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
iscrafmпонятно, т.е. ничего серьезного не делал, типа только внедрения 1С. [youtube= ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 16:53 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
iscrafmMonochromatiqueТогда расскажешь, как восстановить партионный учет с количеством складских документов 2000 в день за полчаса не прерывая работы пользователей и не мешая им? элементарно: организовать параллельный ввод, а в основном сделать партионный учет, и добавить затем введенные новые документы. Задача простая и количество документов здесь конечно-же не при чем Вот давай без обид, ок? Это вообще не ответ на вопрос. -- Как сделать живой партионный учет на 2000 доков в день? -- Надо его... Сделать! -- Вы приняты! Ты, видимо просто не понимаешь проблемы. Поэтому этот вопрос и задаётся 1С-нику, потому что предметная область там узкая, а стереотипы - устоявшиеся. Понятно, что любой нормальный прог прощелкает это как семечки. Но твой ответ - за гранью и вне контекста реальной проблемы. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 16:58 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
MonochromatiqueСколько людей поддерживает? Насколько она сопротивляется изменениям? Это кому-то тут интересно?)))) вроде у тебя были вопросы? я могу только постебаться с программера с завышенным ЧСВ, который по сути не понимает элементарных вещей Monochromatique2000 документов, 150 магазинов - это показатель масштабируемости где и когда это вдруг стало показателем масштабируемости? ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 16:59 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
Monochromatiqueiscrafmпропущено... элементарно: организовать параллельный ввод, а в основном сделать партионный учет, и добавить затем введенные новые документы. Задача простая и количество документов здесь конечно-же не при чем Вот давай без обид, ок? Это вообще не ответ на вопрос. -- Как сделать живой партионный учет на 2000 доков в день? -- Надо его... Сделать! -- Вы приняты! я такими проектами 20 лет занимаюсь. Что ты привязался к какой-то цифре 2000 каких-то доков в день? ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 17:01 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
Злой Бобр авторКоличество документов не является показателем. Ну как не является-то, мусье! На сотне документов всё летает, на 10 000 всё ложится. Что же это за показатель?? авторИ при больших объемах я вообще не стал бы вести партионный учет в том виде в котором он есть в типовых конфигурациях. А никто и не говорит про типовые. авторБольшие обемы по моим меркам 10к+ документов в день с количеством записей 100+ . И да, это на 7.7 и это не фантастика. Ага. С применением сторонних компонент, после ряда которых поднимается вопрос - а зачем нам вообще 1С? автор Более того для 1С не может быть понятия архитектор. Ну вот, уже и архитектор не нужен. Кто ж у нас остается то? ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 17:05 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
MonochromatiqueЭто чистая разработка. С внедрением конечно. Когда мы начинали дистрибьюторский проект, 1С вообще ничего на такой объем не предлагала. Даже для 7.7 это мелкий объем. Поэтому не говорите что нельзя было сделать на 1С. Это даже не смешно, т.к. многие успешно это делали. Monochromatique2000 документов, 150 магазинов - это показатель масштабируемости - чем еще систему в моменте мерять то? Сколько людей поддерживает? Насколько она сопротивляется изменениям? Это кому-то тут интересно?)))) Это не показатель масштабируемости. Сюда же добавляйте количество пользователей и т.п. Масштабируемость - это работа под разными ОС, разными устройствами и пр. Но опять же - к 1С это не относится. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 17:07 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
iscrafmвроде у тебя были вопросы? я могу только постебаться с программера с завышенным ЧСВ, который по сути не понимает элементарных вещей Но у тебя нет на них ответов. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 17:12 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
Monochromatiqueiscrafmвроде у тебя были вопросы? я могу только постебаться с программера с завышенным ЧСВ, который по сути не понимает элементарных вещей Но у тебя нет на них ответов. ты тему не читаешь? А что ты тогда здесь делаешь? ЧСВ тешишь? ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 17:13 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
Злой БобрМасштабируемость - это работа под разными ОС, разными устройствами и пр. Но опять же - к 1С это не относится. Бобр, ты почитай что такое масштабируемость. Можешь вместе с Искрой, у него тоже какие-то проблемы. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 17:14 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
Monochromatiqueiscrafmвроде у тебя были вопросы? я могу только постебаться с программера с завышенным ЧСВ, который по сути не понимает элементарных вещей Но у тебя нет на них ответов. 18455302 просто ответы неудобны, судя по всему, вопрошающему. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 17:16 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
MonochromatiqueНо у тебя нет на них ответов. - Дядя, дядя. Научи меня ... - Иди мальчик отсюда. Тут тебе не учкомбинат. Ну как-то так. На форуме вас учит никто ничему не будет. Вы все так же можете продолжать скулить о своей нелегкой судьбе. Но думаю всем уже на это глубоко ... Надеюсь лет через 5 прочтете свою тему и улыбнетесь. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 17:17 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
Злой БобрДаже для 7.7 это мелкий объем. Поэтому не говорите что нельзя было сделать на 1С. Это даже не смешно, т.к. многие успешно это делали. )))) Что делали-то??? Я говорю не про ввод данных (отсылка к пользователям), или снятие отчетов, а про обработку данных. Которая в 1С (в то время) была совмещена вместе с вводом и от того - нещадно жрала ресурсы. Это всё 1С-вские стереотипы, своего рода паттерн. Просто рядовой 1С-ник ничего другого не знает (и знать не хочет) - от того и проблемы. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 17:17 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
MonochromatiqueЗлой БобрМасштабируемость - это работа под разными ОС, разными устройствами и пр. Но опять же - к 1С это не относится. Бобр, ты почитай что такое масштабируемость. Можешь вместе с Искрой, у него тоже какие-то проблемы. бестолковый, но борзый, судя по всему ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 17:17 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
iscrafmMonochromatiqueпропущено... Бобр, ты почитай что такое масштабируемость. Можешь вместе с Искрой, у него тоже какие-то проблемы. бестолковый, но борзый, судя по всему он слишком долго фрилансил ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 17:23 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
iscrafmMonochromatiqueпропущено... Но у тебя нет на них ответов. 18455302 просто ответы неудобны, судя по всему, вопрошающему. Это не ответы - это треш. Не знаю, как ты это продаешь. Насмотрелся я на таких менеджеров, в одном они сильны - говно на лопате они называют конфетой. Какое-то время даже получается. -- Как убедиться, что архитектура отвечает потребностям решения? -- Ну её же делал архитектор! -- Как быстро восстановить партионный учет? -- Надо его сделать быстрым!! Ша-пи-то. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 17:23 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
iscrafmбестолковый, но борзый, судя по всему Ну зачем так грубо. Набьет шишек, наберется опыта и потом сам поймет. Я будучи "студентом" тоже думал что 1С решает все. Но только со временем понял насколько 1С - зло. Сейчас думаю - и как мне руки не повыдергивали за тот быдлокод который я ваял налево и направо. Так что побыдлокодив лет 5 - тоже научится. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 17:23 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
Злой Бобр Я будучи "студентом" тоже думал что 1С решает все. Но только со временем понял насколько 1С - зло. Тебя ждет еще столько удивительных открытий.... ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 17:26 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
Monochromatiqueiscrafmпропущено... 18455302 просто ответы неудобны, судя по всему, вопрошающему. Это не ответы - это треш. Не знаю, как ты это продаешь. вопрос: каким образом получить исчерпывающие описание системы? ответ: дать задание подготовить описание его автору. Оказывается MonochromatiqueЭто не ответы - это треш. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 17:33 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
Злой Бобрiscrafmбестолковый, но борзый, судя по всему Ну зачем так грубо. Набьет шишек, наберется опыта и потом сам поймет. приношу извинения. Я же со смайлом, т.е. "без зла" ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 17:34 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
iscrafmMonochromatiqueпропущено... Это не ответы - это треш. Не знаю, как ты это продаешь. вопрос: каким образом получить исчерпывающие описание системы? ответ: дать задание подготовить описание его автору. Оказывается MonochromatiqueЭто не ответы - это треш. Да не - всё ровно. Ты меня научил. С аналитика - анализ. С Архитектора - архитектура. С HR - проги. С ТимЛида - дисциплина. С Кодеров - код. Бабки - мне. Вот это да. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 17:35 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
Monochromatique, Хватит выяснять отношения. Парню выделили бюджет, дали возможность команду набрать, а он хочет командой командами управлять. Щас у парня проект провалится, бабки заберут, и не факт, что остальным дадут доделывать.... Вы, Monochromatique, как руководитель попробуйте забыть на время, что такое программирование, архитектура и 2000 документов в день. Ваша забота найти (распределить) ответственность (аналитик, архитектор, программист, ..., уборщица), определить способы стимулирования и способы контролирования. Но только не Вы должны вмешиваться в код или технологии - это теперь не Ваша специализация. Отношения между сотрудниками должны быть выстроены так: Пользователь пишет отзыв о работе аналитика, аналитик жалуется на архитектора, архитектор пинает программера, за всеми наблюдает менеджер проекта и следит чтоб все работы вовремя были. И вообще, если Вы такой опытный, на х...р Вам 10 человек команда? Сделали бы все сами по старинке! ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 17:36 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
MonochromatiqueС аналитика - анализ. С Архитектора - архитектура. С HR - проги. С ТимЛида - дисциплина. С Кодеров - код. для тебя это открытие? ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 17:37 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
iscrafmприношу извинения. Я же со смайлом, т.е. "без зла" Мне то всеравно, но люди разные бывают. Вдруг человек расстроится. Возьмет и спрыгнет с этажа и т.п. Потом будешь доказывать что ты не доводил человека до этого. За это ж вроде как и статья есть. Оно тебе нада?.. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 17:38 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
sereginsereginОтношения между сотрудниками должны быть выстроены так: Пользователь пишет отзыв о работе аналитика, аналитик жалуется на архитектора, архитектор пинает программера, за всеми наблюдает менеджер проекта и следит чтоб все работы вовремя были. ты слишком уж очевидные вещи говоришь. Он же сказал MonochromatiqueЭто не ответы - это треш. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 17:40 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
sereginsereginMonochromatique, Хватит выяснять отношения. Парню выделили бюджет, дали возможность команду набрать, а он хочет командой командами управлять. Щас у парня проект провалится, бабки заберут, и не факт, что остальным дадут доделывать.... Вы, Monochromatique, как руководитель попробуйте забыть на время, что такое программирование, архитектура и 2000 документов в день. Ваша забота найти (распределить) ответственность (аналитик, архитектор, программист, ..., уборщица), определить способы стимулирования и способы контролирования. Но только не Вы должны вмешиваться в код или технологии - это теперь не Ваша специализация. Отношения между сотрудниками должны быть выстроены так: Пользователь пишет отзыв о работе аналитика, аналитик жалуется на архитектора, архитектор пинает программера, за всеми наблюдает менеджер проекта и следит чтоб все работы вовремя были. И вообще, если Вы такой опытный, на х...р Вам 10 человек команда? Сделали бы все сами по старинке! Извиняюсь, возможно покажется свысока - но хоть первый отзыв в тему! По поводу опыта - ну рано или поздно масштабы системы превосходят возможности одного человека. Особенно, когда сжимают сроки. Тут нет никаких иллюзий. Из ваших слов, я не пойму - кто (КТО) определяет, как должен выглядеть финальный продукт. Архитектор? То есть, если заказчик настаивает на нежизнеспособном говне, а архитектор именно это и делает, но получается некая подпись по неким дизайн-документом обеспечивает спокойный сон PM-а? Иными словами, у PM-а главное - акт приема-передачи, а не качество решения? ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 17:45 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
MonochromatiqueИными словами, у PM-а главное - акт приема-передачи, а не качество решения? Для 1С - да. У многих франчей продажа коробки = внедрение. И поскольку 1С такая практика устраивает - смысл вам идти против течения. Талько не акт приема-передачи, а ... [специально пропущу, ну хоть немного ж нужно извилинами шевельнуть]. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 17:50 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
sereginseregin определить способы стимулирования и способы контролирования. Тут вся тема о том, кто какие способы контролирования использует. Какие инструментами пользуется. И причем не кодеров. Коллег, просто тут немного унесло в сторону. Но их можно понять, они из-зо всех сил пытаются сообщить мне что-то важное. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 17:50 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
MonochromatiqueИными словами, у PM-а главное - акт приема-передачи, а не качество решения? его задача достич всеобщего удовлетворения в требуемый срок и в рамках бюджета. Качеством решения занимается в основном архитектор, имея "по рукой" исполнителей в виде программистов и и проверяющих в виде аналитиков ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 17:53 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
MonochromatiqueПо поводу опыта - ну рано или поздно масштабы системы превосходят возможности одного человека. Особенно, когда сжимают сроки. Тут нет никаких иллюзий. Из ваших слов, я не пойму - кто (КТО) определяет, как должен выглядеть финальный продукт. Архитектор? То есть, если заказчик настаивает на нежизнеспособном говне, а архитектор именно это и делает, но получается некая подпись по неким дизайн-документом обеспечивает спокойный сон PM-а? Иными словами, у PM-а главное - акт приема-передачи, а не качество решения? Если Ваших личных возможностей не хватает, сроки подживают, тогда выбирайте: 1. Делаете как считаете нужным, но сами; ИЛИ 2. Делегируете работу другим, понимая, что сколько людей - столько и мнений. Если заказчик благодарен, значит проект удачен. Выявленные расхождения между специалистами корректируются на следующем проекте. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 17:56 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
Злой БобрMonochromatiqueИными словами, у PM-а главное - акт приема-передачи, а не качество решения? Для 1С - да. У многих франчей продажа коробки = внедрение. И поскольку 1С такая практика устраивает - смысл вам идти против течения. Талько не акт приема-передачи, а ... [специально пропущу, ну хоть немного ж нужно извилинами шевельнуть]. Еще раз - меня не интересует продажа коробок или "доработка" типового функционала. Меня интересуют способы контроля звеньев на всём этапе чистой разработки. В случае с .NET\JAVA я понимаю как контролировать кодеров. В случае с 1С - не понимаю. Только административные рычаги. Ну или костыли. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 17:58 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
Играл как-то в теннис с одним дядькой. Его компания писала ПО, которая должны была решать Vehicle routing problem . Прогеров (JAVA) там было на два этажа. Так вот он даже не знал, какую БД они в своем решении используют. Мне это тогда показалось удивительным. По мне так - вопрос стратегический. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 18:03 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
Monochromatiquesereginseregin определить способы стимулирования и способы контролирования. Тут вся тема о том, кто какие способы контролирования использует. Какие инструментами пользуется. И причем не кодеров. Коллег, просто тут немного унесло в сторону. Но их можно понять, они из-зо всех сил пытаются сообщить мне что-то важное. для того чтобы узнать что-то новое нужно задавать вопросы и внимательно слушать а не делать вид что ты все это уже знаешь и теперь готов устроить конкурс на предмет, удовлетворит ли тебя танец с саблями и прочие фокусы-акробатика других участников в попытке максимально обстоятельно и интересно изобразить тебе в картинках все то чего ты на самом деле не знаешь и ты потом такой все по-буквенно перестрочил в блокнотик а отвечавшим и комментировавшим со все теми же апломбом и надменностью сообщил что в целом они тоже молодцы, но еще есть чему поучиться. в целом, конечно, риторика - от полного детского сада до каких-то даже относительно удачных попыток. особенно забавно - обвинение других участников в том что все что они пишут - это цирк и шапито. обрати внимание, где ты попытался выехать за счет опыта и знаний. на прогерско-админско-внедренских (не силен к чему это относится) вопросах про 1С. если мозг не полностью выелся фрилансом и остались еще возможности для допущения собственной некомпетентности в каких бы там ни было вопросах, то надо в первую очередь самому себе признаться что пробел и нехилый такой имеется. делать вид что он "не имеется" - не получается. тест на форуме вроде как дал это понять. одна из проблем долгофрилансеров - они никогда не видели живых архитекторов, аналитиков, тимлидов, пиэмов и понятия не имеют, кто эти люди, чем они занимаются, как выглядит результат их работы. скрытые (почему-то) вопросы об этом и подтверждения отсутствия этих знаний проявляются на протяжении всего обсуждения. при этом почему-то сохраняется позиция: вы тут дети, пришел отец, быстренько доложили шо там в проектном менеджменте. минут за семь. пошевеливаемся, пошевеливаемся. направление движения с таким подходок, как мне кажется, недвусмысленно уже многократно указано. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 18:05 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
MonochromatiqueВ случае с 1С - не понимаю. Только административные рычаги. Ну или костыли. Да все так же как и в других системах. Роль архитектора выполняет ведущий программист (назовем так), кодеры - программисты, тестеры - аналитики. От вас как от ПМ потребуется составить ТЗ по запросам клиента. Если сами неумеете - берите к клиенту и вашего программера. Он исходя из опыта сможет поставить правильные вопросы и набросать предварительную схему. Дальше уже более детально расписываете схему в виде ТЗ (с формочками, графиками и пр.). После того как ТЗ готово, разбиваете на узлы и определяете примерное время на реализацию каждого. Программист делает каркас конфигурации, после чего раздает работу остальным. По мере выполнения собирает все в кучу и отдает готовое тестерам. Ну и т.д. Вроде ж все элементарно. Ну немогу понять - что вызывает такие трудности?.. Со стороны ПМ должны быть оглашены четкие условия. Т.е. если кто-то про... и со сроками задержка - минус столько-то денег. Если проект сдан досрочно - плюс столько-то денег. Ну и т.п. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 18:08 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
MonochromatiqueТак вот он даже не знал, какую БД они в своем решении используют. я сегодня MS SQL, завтра FireBird, после завтра ORACLE... Действительно какая разница ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 18:10 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
sereginsereginДелегируете работу другим, понимая, что сколько людей - столько и мнений. Но мне это не нужно. Не должно быть "столько и мнений". Мнение одно - спускается сверху. Вопрос - в каком виде его спустить и как проконтролировать, что всё в рамках протокола. У меня был неудачный опыт - программист с порученной задачей не справился. То есть - на тестовом объеме (и на реальных людях) всё работало, а на реальных объёмах всё ложилось. Поняли поздно. Пришлось в аврале всё переделывать. + Месяц. То есть - человеку было отдано больше компетенций, чем следовало. Виноват, очевидно, был я. Повторений не хочется. А прогер-то был - выше среднего. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 18:12 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
MonochromatiqueМнение одно - спускается сверху. возрождение совковых привычек не принесет профита. Нужно научится слушать. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 18:15 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
MonochromatiqueИграл как-то в теннис с одним дядькой. Если дядька является владельцем компании, то поверь - ему действительно всеравно. И даже всеравно сколько рабов на него батрачат. Он вложил денег и желает получать определенную сумму. А как там исполнительный будет крутиться - да пофиг (мягко выражаясь). И такой подход абсолютно верный. Куда хуже когда владельцы пытаются рулить бизнесом в котором непонимают. Вот тогда полный писец всем кто там работает. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 18:15 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
Злой БобрВроде ж все элементарно. Ну немогу понять - что вызывает такие трудности?.. Ты когда нибудь делал авторДальше уже более детально расписываете схему в виде ТЗ (с формочками, графиками и пр.). На 500+ форм? Где ты это делал? ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 18:15 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
MonochromatiqueУ меня был неудачный опыт - программист с порученной задачей не справился. То есть - на тестовом объеме (и на реальных людях) всё работало, а на реальных объёмах всё ложилось. Поняли поздно. Пришлось в аврале всё переделывать. + Месяц. То есть - человеку было отдано больше компетенций, чем следовало. Виноват, очевидно, был я. Повторений не хочется. А прогер-то был - выше среднего прогер здесь совершенно не при чем. Архитектор где-то "накосячил" ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 18:16 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
Злой БобрMonochromatiqueИграл как-то в теннис с одним дядькой. Если дядька является владельцем компании, то поверь - ему действительно всеравно. И даже всеравно сколько рабов на него батрачат. Он вложил денег и желает получать определенную сумму. А как там исполнительный будет крутиться - да пофиг (мягко выражаясь). И такой подход абсолютно верный. Куда хуже когда владельцы пытаются рулить бизнесом в котором непонимают. Вот тогда полный писец всем кто там работает. Но конкретно тому бизнесу он и так настал. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 18:16 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
JE SUIS ЦКтолько процесс их изменения должен быть контролируемый и управляемый кто кому должен? есть ТЗ. если оно это не покрывает, и это лежит в области договоренностей "по-рукам", то дальше как карта ляжет ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 18:17 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
iscrafmMonochromatiqueУ меня был неудачный опыт - программист с порученной задачей не справился. То есть - на тестовом объеме (и на реальных людях) всё работало, а на реальных объёмах всё ложилось. Поняли поздно. Пришлось в аврале всё переделывать. + Месяц. То есть - человеку было отдано больше компетенций, чем следовало. Виноват, очевидно, был я. Повторений не хочется. А прогер-то был - выше среднего прогер здесь совершенно не при чем. Архитектор где-то "накосячил" Ок. 1. Где? 2. Как понять это ДО начала разработки? 3. Кто должен понять, что архитектор накосячил? ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 18:17 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
MonochromatiqueЗлой Бобрпропущено... Если дядька является владельцем компании, то поверь - ему действительно всеравно. И даже всеравно сколько рабов на него батрачат. Он вложил денег и желает получать определенную сумму. А как там исполнительный будет крутиться - да пофиг (мягко выражаясь). И такой подход абсолютно верный. Куда хуже когда владельцы пытаются рулить бизнесом в котором непонимают. Вот тогда полный писец всем кто там работает. Но конкретно тому бизнесу он и так настал. Тот дядька грант получил. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 18:18 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
MonochromatiqueЯ - отвечаю за проекты в целом и целиком тогда нагибать, лишать, заставлять ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 18:19 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
iscrafmпрогер здесь совершенно не при чем. Архитектор где-то "накосячил" На самом деле перед клиентом отвечает всегда ПМ, а не программист Вася. Клиент вообще должен общаться только с ПМ. Тогда и программисты будут работать спокойно и ПМ будет знать что и как. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 18:20 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
kmawMonochromatiqueЯ - отвечаю за проекты в целом и целиком тогда нагибать, лишать, заставлять + приковывать наручниками к батарее и не отпускать пока проект не сдашь. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 18:22 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
MonochromatiqueНа какие этапы участники форума бьют задачи гост 34 ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 18:22 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
Monochromatiqueiscrafmпропущено... прогер здесь совершенно не при чем. Архитектор где-то "накосячил" Ок. 1. Где? 2. Как понять это ДО начала разработки? 3. Кто должен понять, что архитектор накосячил? 1. архитектор должен найти место, где он "накосячил" 2. никак. Для этого есть итеративная модель разработки 3. архитектор должен признать что он "накосячил" и указать место где его подчиненный, как исполнитель, "накосячил" ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 18:22 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
Злой Бобрiscrafmпрогер здесь совершенно не при чем. Архитектор где-то "накосячил" На самом деле перед клиентом отвечает всегда ПМ, а не программист Вася. Клиент вообще должен общаться только с ПМ. Тогда и программисты будут работать спокойно и ПМ будет знать что и как. у нас клиент всегда с аналитиком общается. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 18:23 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
способы стимулирования, Насмешил. В хорошем смысле. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 18:23 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
MonochromatiqueВерю, что разработку можно превратить в конвейер пока не узнаешь как, верь ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 18:24 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
MonochromatiqueОдин из моих проектов выложен на этом форуме кинь тынц, плиз ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 18:25 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
Monochromatiqueiscrafmпропущено... нужен просто нормальный архитектор, а не ярлык архитектора Как за полчаса на собеседовании понять, что перед вами хорший архитектор или PM? зп 250+ ? ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 18:28 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
MonochromatiquesereginsereginДелегируете работу другим, понимая, что сколько людей - столько и мнений. Но мне это не нужно. Не должно быть "столько и мнений". Мнение одно - спускается сверху. Вопрос - в каком виде его спустить и как проконтролировать, что всё в рамках протокола. У меня был неудачный опыт - программист с порученной задачей не справился. То есть - на тестовом объеме (и на реальных людях) всё работало, а на реальных объёмах всё ложилось. Поняли поздно. Пришлось в аврале всё переделывать. + Месяц. То есть - человеку было отдано больше компетенций, чем следовало. Виноват, очевидно, был я. Повторений не хочется. А прогер-то был - выше среднего. Если программер с заказчиком напрямую не работает, может не знать объема его данных, потому решает задачу так, как ему поставлено. Кто задачу ставил, тот и должен был тестовый пример придумать и проконтролировать исполнение (своеобразный акт приемо-передачи подписать). Другого тут нечего придумывать. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 18:29 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
iscrafmу нас клиент всегда с аналитиком общается. Ну вероятно в плане того что сделано, а не того что хочу еще то и еще вон то. Потому как когда программистам начинают гадить своими хотелками, то рано или поздно наступит срыв. Поэтому в идеале программисты вообще не должны контактировать с клиентами. Тогда будет порядок. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 18:29 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
Злой Бобрiscrafmу нас клиент всегда с аналитиком общается. Ну вероятно в плане того что сделано, а не того что хочу еще то и еще вон то. Потому как когда программистам начинают гадить своими хотелками, то рано или поздно наступит срыв. Поэтому в идеале программисты вообще не должны контактировать с клиентами. Тогда будет порядок. аналитик это не программист. Это, допустим, высокообразованный специалист, который не умеет программировать, но очень хорошо знает во-первых чего хочет от программы клиент, а во-вторых, насколько сделанное программистом по задумке архитектора отвечает тому, что хочет клиент. Но не программист и не ПМ (адиминистратор, организатор по сути) ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 18:37 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
MonochromatiqueЗлой Бобрпропущено... Да. Параллельно нанимайте студентов, которые через 3-5 лет смогут вырасти до необходимого уровня. Опять же бестолковые сами со временем отсеются. Студенты?? Вырасти за три-пять лет?? Любезный Злой Бобр, я не ГЭС строю. нормальные за год два вполне вырастают и обгоняют ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 18:40 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
MonochromatiqueИными словами, у PM-а главное - акт приема-передачи, а не качество решения? У РМ-а есть его любимый треугольник: функционал/бюджет-ресурсы/сроки. Это все, что его должно волновать. За качество решения отвечают другие люди (в этом топике их называли архитекторами и программистами). ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 18:41 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
iscrafmMonochromatiqueИными словами, у PM-а главное - акт приема-передачи, а не качество решения? его задача достич всеобщего удовлетворения в требуемый срок и в рамках бюджета. Качеством решения занимается в основном архитектор, имея "по рукой" исполнителей в виде программистов и и проверяющих в виде аналитиков +1 ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 18:42 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
MonochromatiqueУ меня был неудачный опыт - программист с порученной задачей не справился. То есть - на тестовом объеме (и на реальных людях) всё работало, а на реальных объёмах всё ложилось. Очевидно, не было нефункциональных требований по нагрузке и нагрузочного тестирования перед сдачей. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 18:45 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
MonochromatiquesereginsereginДелегируете работу другим, понимая, что сколько людей - столько и мнений. Но мне это не нужно. Не должно быть "столько и мнений". Мнение одно - спускается сверху. Вопрос - в каком виде его спустить и как проконтролировать, что всё в рамках протокола. У меня был неудачный опыт - программист с порученной задачей не справился. То есть - на тестовом объеме (и на реальных людях) всё работало, а на реальных объёмах всё ложилось. Поняли поздно. Пришлось в аврале всё переделывать. + Месяц. То есть - человеку было отдано больше компетенций, чем следовало. Виноват, очевидно, был я. Повторений не хочется. А прогер-то был - выше среднего. программист с задачей справился на 100% ему была предоставлена задача, реальные люди и тестовые объемы на этапе обследования не были выявлены реальные потребности, не были спрогнозированы объемы не были выявлены нефункциональные требования, критически влияющие на архитектуру (на важные решение, принятые при проектировании) в стартовых постах также было много про требования. надо читать про работу с требованиями (Вигерс (!), Леффингуэл(точно не помню как пишется)), их роль в проекте и все что должен не упустить пм (шапито-трешовый-банальный pmbok) pmbok, гост, книжки говорят об очень многих вещах, которые _вы_могли_бы_упустить_не_будучи_знакомыми_с_информацией_из_этих_источников_ все эти "тыщи пунктов не имеющие отношения к вашему проекту" - это всё то, о чем очень важно не забыть. также работу с требованиями надо сопоставить с тем, что вы называете вашей методологией. то ли вы описываете сначала всё и досконально, то ли кусками, то ли тяп-ляп, простое в почте, сложное - тады пишем. из методологии и того же pmbok'а можно узнать про роли (пока - о работе с требованиями): кто что делает, кто чего не делает, чьи подписи собирать, а кто - обойдется чтоб еще и на нем все стопорилось. масса базовых вопросов про вообще управление, вообще делегирование, вообще контроль. про вообще процессы. веет типичными хаотичными сквозными вбросами: хотелка->(именно летящая заточенная стрела)прогер->продакшен->фейл->сроки->"ребята, простите меня, я виноват. я не догадался что вы криворукие и тупые, я недостойный руководитель, вы не получите зарплаты. спасибо за внимание". странные реплики про понимание процессов в java и непонимание процессов 1с. это ж про процессы разработки. это ж процессы. не технологии. там разная инфраструктура и код. при чем тут процессы. осмысленное объяснение которое находится - микроменеджмент. т.е. зная код java вы ковыряетесь в коде подчиненных программистов. вместо организации процессов, делегирования, контроля. кодища 1с не знаете (я так понял) - все, никакого управления. так это и не было управлением. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 18:46 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
kmawJE SUIS ЦКтолько процесс их изменения должен быть контролируемый и управляемый кто кому должен? есть ТЗ. если оно это не покрывает, и это лежит в области договоренностей "по-рукам", то дальше как карта ляжет Тот, кому интересен на выходе продукт, который удовлетворит заказчика (и за который он немалые деньги заплатит в итоге). Если такой цели нет - тогда никто никому ничего не должен, нехай растет, как растет... ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 18:47 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
Тут вся тема о томстранные реплики про понимание процессов в java и непонимание процессов 1с. это ж про процессы разработки. это ж процессы. не технологии. там разная инфраструктура и код. при чем тут процессы. осмысленное объяснение которое находится - микроменеджмент. т.е. зная код java вы ковыряетесь в коде подчиненных программистов. вместо организации процессов, делегирования, контроля. кодища 1с не знаете (я так понял) - все, никакого управления. так это и не было управлением. Да нет там ничего странного. Если правильно вопрос ТС-а сформулировать: "Как в 1С ограничить работу одного программиста, чтобы он писал только свой модуль и не трогал чужие?" ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 18:53 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
Тут вся тема о томстранные реплики про понимание процессов в java и непонимание процессов 1с. это ж про процессы разработки. это ж процессы. не технологии. там разная инфраструктура и код. при чем тут процессы. осмысленное объяснение которое находится - микроменеджмент. т.е. зная код java вы ковыряетесь в коде подчиненных программистов. Нет. В типизированном языке я могу спустить сверху описание бизнес-логики (ну грубо) в виде интерфейсов и никакой кодер не рыпнется в сторону. Даже если BL будет реализовна неправильно (на самом деле так, или кодер так подумал) - проблема будет ВЫНУЖДЕНА подняться до проектировщика интерфейса. А в 1С нет такой возможности - и потенциально - каждый может наирачить что захочет. У одного пардон запрос в цикле, у другого пара слоев ему только-ему-понятной абстракции. И что с этим потом делать? ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 18:59 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
MonochromatiqueВ типизированном языке я могу спустить сверху описание бизнес-логики (ну грубо) в виде интерфейсов и никакой кодер не рыпнется в сторону это бред ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 19:00 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
MonochromatiqueИ что с этим потом делать вопроса потом не стоит, особенно для разработки командой из 10 чел. это означает фейл ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 19:02 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
JE SUIS ЦКТут вся тема о томстранные реплики про понимание процессов в java и непонимание процессов 1с. это ж про процессы разработки. это ж процессы. не технологии. там разная инфраструктура и код. при чем тут процессы. осмысленное объяснение которое находится - микроменеджмент. т.е. зная код java вы ковыряетесь в коде подчиненных программистов. вместо организации процессов, делегирования, контроля. кодища 1с не знаете (я так понял) - все, никакого управления. так это и не было управлением. Да нет там ничего странного. Если правильно вопрос ТС-а сформулировать: "Как в 1С ограничить работу одного программиста, чтобы он писал только свой модуль и не трогал чужие?" Да. И писал так, как нужно. Очевидно недостачным будет сказать - пиши как надо. Тот пожмет плечами и напишет какой-нибудь запрос на 25 страниц. Его надо как-то ограничить. Но это кодинг, там всё понятно, более/менее. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 19:05 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
kmawMonochromatiqueВ типизированном языке я могу спустить сверху описание бизнес-логики (ну грубо) в виде интерфейсов и никакой кодер не рыпнется в сторону это бред Почему?? ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 19:05 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
kmawMonochromatiqueИ что с этим потом делать вопроса потом не стоит, особенно для разработки командой из 10 чел. это означает фейл Ну, если это поднимается хоть как-то, то ПОТОМ наступает очень быстро. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 19:06 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
MonochromatiqueJE SUIS ЦКпропущено... Да нет там ничего странного. Если правильно вопрос ТС-а сформулировать: "Как в 1С ограничить работу одного программиста, чтобы он писал только свой модуль и не трогал чужие?" Да. И писал так, как нужно. Очевидно недостачным будет сказать - пиши как надо. Тот пожмет плечами и напишет какой-нибудь запрос на 25 страниц. Его надо как-то ограничить. Но это кодинг, там всё понятно, более/менее. На такого рода вопросы (зеленым выше) я всегда задаю встречный вопрос: "Зачем?" И ответ на него почти всегда находится в совершенно другой плоскости. Ваш пример - рискну предположить, что ограничивать вы собрались для того, чтобы там не появился говнокод с метастазами по всему проекту. И проблема на самом деле не в том, что в 1С ограничений недостаточно, а во том, что ваши коллеги-подчиненные лабают говнокод. И тут надо следующий логичный вопрос задать... ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 19:14 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
Monochromatiquekmawпропущено... это бред Почему?? потому что интерфейсы - это не данность из ТЗ, а рабочие моменты ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 19:15 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
JE SUIS ЦК а во том, что ваши коллеги-подчиненные лабают говнокод. И тут надо следующий логичный вопрос задать... У каждого свое понятие говнокода. Для меня хороший код - это код, который может исправить/разобраться любой сосед/новый нанятый сотрудник. Для программиста, которому скучно на работе - хороший код, это абстрактная заумь, на которую все будут смотреть и восхищенно цокать языками. Этот case порой рождает таких монстров, что реально проще переписать всё заново. Для матерых 1С-ников, например, характерно писать свой конфигуратор поверх платформы. Типа не надо лазать в конфигуратор!! Правда по факту - только он и может справится со своей системой. Поэтому на мой взгляд проще правила внушить одному, а остальных _заставить_ им следовать. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 19:22 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
kmawMonochromatiqueпропущено... Почему?? потому что интерфейсы - это не данность из ТЗ, а рабочие моменты Всё равно не понял - почему спустить интерфейс кодеру - это бред. И это не рабочие моменты - а общий дизайн приложения как такового. Иначе, всё будет еще хуже чем в 1С - уж у сишников/явистов руки вообще развязаны. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 19:24 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
MonochromatiqueА в 1С нет такой возможности - и потенциально - каждый может наирачить что захочет. У одного пардон запрос в цикле, у другого пара слоев ему только-ему-понятной абстракции. И что с этим потом делать? сменить на что-то нормальное или архитектор должен четко программеру указать, что Monochromatiqueпара слоев ему только-ему-понятной абстракции. не проходит ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 19:25 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
MonochromatiqueДля матерых 1С-ников, например, характерно писать свой конфигуратор поверх платформы это еще что такое? ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 19:25 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
Monochromatiquekmawпропущено... это бред Почему?? Потому что с людьми нужно договариваться. Все о чем договоришься, они выполнят в деталях (зарплаты никто лишаться не хочет). Но если что-то упустил, тут их фантазия не имеет границ. Они проявят гениальность. Некоторые, в рамках твоих ограничений, принципиально пакость сделают, но прикинутся глуповатыми, мол сами не знали как так вышло. Другие внедрят супер-пупер быстрый алгоритм, используя дырки в системе и не требуя за это дополнительного вознаграждения. И проект может как взлететь, так и упасть... ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 19:27 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
MonochromatiqueИ это не рабочие моменты - а общий дизайн приложения как такового 95% CRUD (что там кому спускать?). 5% - специфика, которая на этапе спускания просто не известна/непонятна ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 19:27 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
iscrafmMonochromatiqueА в 1С нет такой возможности - и потенциально - каждый может наирачить что захочет. У одного пардон запрос в цикле, у другого пара слоев ему только-ему-понятной абстракции. И что с этим потом делать? сменить на что-то нормальное или архитектор должен четко программеру указать, что Monochromatiqueпара слоев ему только-ему-понятной абстракции. не проходит Сказать/указать/Распорядиться - не действенные инструменты. Проще и вернее поставить в рамки технического толка. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 19:34 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
MonochromatiqueТут вся тема о томстранные реплики про понимание процессов в java и непонимание процессов 1с. это ж про процессы разработки. это ж процессы. не технологии. там разная инфраструктура и код. при чем тут процессы. осмысленное объяснение которое находится - микроменеджмент. т.е. зная код java вы ковыряетесь в коде подчиненных программистов. Нет. В типизированном языке я могу спустить сверху описание бизнес-логики (ну грубо) в виде интерфейсов и никакой кодер не рыпнется в сторону. Даже если BL будет реализовна неправильно (на самом деле так, или кодер так подумал) - проблема будет ВЫНУЖДЕНА подняться до проектировщика интерфейса. попытка реализовать микроменеджмент технически для компенсации эффектов отсутствия процессов и управления в целом, такой "микроменеджмент" вполне может даже позитивно существовать - см. те же прекоммит-хуки но это не есть сам процесс. это один из элементов инфраструктуры, созданной под процесс. "спуск интерфейсов" - вполне может быть даже частью системных требований. но речь не об интерфейсах реализованных/задекларированных в каком-то коде. PM пишет юнит с декларацией интерфейсов?.. архитектор, в целом, может. или тимлид. или сам программист, который должен эту задачу реализовать. MonochromatiqueА в 1С нет такой возможности - и потенциально - каждый может наирачить что захочет. У одного пардон запрос в цикле, у другого пара слоев ему только-ему-понятной абстракции. это отсутствие квалификации (исполнителя), отсутствие контроля, отсутствие работы с персоналом. где был код-ревью? где был руководитель, который (не)декомпозировал и назначил задачу? он что, не в курсе квалификации сотрудников? где был тимлид ,который должен быть в курсе квалификации тиммэйтов? если никто этим программистом (джуниором-студентом или почти сеньором с завышенным чсв и стремлением к абстракциям) не занимается, если у архитектора нет никаких мыслей, у руководителя нет ничего кроме двух с половиной абзацев в ворде - то что вы хотите? чтобы он все угадал? чтобы как в матрице "закачал себе управление вертолетом" и налабал запрос не в цикле? он же не умеет, если пишет запрос в цикле. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 19:36 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
авторПотому что с людьми нужно договариваться. Все о чем договоришься, они выполнят в деталях (зарплаты никто лишаться не хочет). Договариваемся на собеседовании. Потом - работа. За деньги. Qui pro quo Зарплаты у нас никого не лишают - это же абсурд. Расстаться можем, но деньгами не наказываем. У нас нет такого бизнес-процесса - подниматься на штрафах. авторОни проявят гениальность. Некоторые, в рамках твоих ограничений, принципиально пакость сделают, но прикинутся глуповатыми, мол сами не знали как так вышло. Другие внедрят супер-пупер быстрый алгоритм, используя дырки в системе и не требуя за это дополнительного вознаграждения. Ты прав. В том то и дело. Поэтому ни днища, ни гении не нужны. Нужен средний предсказуемый результат. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 19:40 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
MonochromatiqueСказать/указать/Распорядиться - не действенные инструменты за все время существования человечества ничего лучше не придумали ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 19:43 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
Monochromatiqueiscrafmпропущено... сменить на что-то нормальное или архитектор должен четко программеру указать, что пропущено... не проходит Сказать/указать/Распорядиться - не действенные инструменты. Проще и вернее поставить в рамки технического толка. просто не умеешь ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 19:45 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
Monochromatiqueни днища, ни гении не нужны. Нужен средний предсказуемый результат. поэтому лада и выглядит как лада а не как ауди. Нужны именно гениальные архитекторы и гениальные программисты. Следить з сроками и бюджетом конечно может и добросовестный ПМ, гении возможно и не нужны ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 19:51 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
Тут вся тема о томMonochromatiqueпропущено... Нет. В типизированном языке я могу спустить сверху описание бизнес-логики (ну грубо) в виде интерфейсов и никакой кодер не рыпнется в сторону. Даже если BL будет реализовна неправильно (на самом деле так, или кодер так подумал) - проблема будет ВЫНУЖДЕНА подняться до проектировщика интерфейса. попытка реализовать микроменеджмент технически для компенсации эффектов отсутствия процессов и управления в целом, такой "микроменеджмент" вполне может даже позитивно существовать - см. те же прекоммит-хуки но это не есть сам процесс. это один из элементов инфраструктуры, созданной под процесс. "спуск интерфейсов" - вполне может быть даже частью системных требований. но речь не об интерфейсах реализованных/задекларированных в каком-то коде. PM пишет юнит с декларацией интерфейсов?.. архитектор, в целом, может. или тимлид. или сам программист, который должен эту задачу реализовать. MonochromatiqueА в 1С нет такой возможности - и потенциально - каждый может наирачить что захочет. У одного пардон запрос в цикле, у другого пара слоев ему только-ему-понятной абстракции. это отсутствие квалификации (исполнителя), отсутствие контроля, отсутствие работы с персоналом. где был код-ревью? где был руководитель, который (не)декомпозировал и назначил задачу? он что, не в курсе квалификации сотрудников? где был тимлид ,который должен быть в курсе квалификации тиммэйтов? если никто этим программистом (джуниором-студентом или почти сеньором с завышенным чсв и стремлением к абстракциям) не занимается, если у архитектора нет никаких мыслей, у руководителя нет ничего кроме двух с половиной абзацев в ворде - то что вы хотите? чтобы он все угадал? чтобы как в матрице "закачал себе управление вертолетом" и налабал запрос не в цикле? он же не умеет, если пишет запрос в цикле. В in-house разработке, особенно там, где производство ПО ДАЛЕКО не основная деятельность - косты режутся до состояния будет/не будет. Какое код-ревью, какая аналитика, какая проработка. Но качество ПОДАЙ. Дали мяч - фуячь, вот и всё ТЗ. С 1С-ом тоже в принципе можно придумать что сделать. Ведь цель - дать адекватную оценку результату за минимальное время. Разработать критерии и т.п. Ок. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 19:52 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
iscrafmMonochromatiqueпропущено... Сказать/указать/Распорядиться - не действенные инструменты. Проще и вернее поставить в рамки технического толка. просто не умеешь Ты не знаешь, чего я умею, чего нет - почему ты мне хамишь? ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 19:53 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
iscrafmMonochromatiqueни днища, ни гении не нужны. Нужен средний предсказуемый результат. поэтому лада и выглядит как лада а не как ауди. Нужны именно гениальные архитекторы и гениальные программисты. Следить з сроками и бюджетом конечно может и добросовестный ПМ, гении возможно и не нужны У меня in-house разработка - я не убийцу facebook-а пишу. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 19:54 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
Monochromatique in-house разработка это что такое? ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 19:57 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
Остался вопрос. В самом начале создается описание системы. Основные понятия, перечисление подсистем, картинки, схемы и прочее. Скажем так - вырастает это всё до сотни страниц. Это по лайту. Зачем это - заказчик хочет ПОНИМАТЬ, что он получит в итоге. Понять он может только текст. Причем околохудожественный. В какие-то короткие сроки такой документ сделать нереально. Качественно сделать, я имею ввиду. Почему - писать можно что угодно. Какие-то системы могут быть несогласованы между собой, какие-то откровенно противоречить. Есть какие-то методики анализа/проверки, что модель описанная текстом - валидна? Проверять программированием - долго. Остаются прототипы? ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 20:03 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
Monochromatiqueiscrafmпропущено... просто не умеешь Ты не знаешь, чего я умею, чего нет - почему ты мне хамишь? с чего ты взял что я тебе хамлю? Я сказал что ты не умеешь, без хамства. А вывод такой я сделал по твоим словам в этом топике и по твоему игнорированию простейшего вопроса kmawMonochromatiqueОдин из моих проектов выложен на этом форуме кинь тынц, плиз покажи проект, не игнорируй, если уж отозвался. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 20:04 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
iscrafmMonochromatiqueпропущено... Ты не знаешь, чего я умею, чего нет - почему ты мне хамишь? с чего ты взял что я тебе хамлю? Я сказал что ты не умеешь, без хамства. А вывод такой я сделал по твоим словам в этом топике и по твоему игнорированию простейшего вопроса kmawпропущено... кинь тынц, плиз покажи проект, не игнорируй, если уж отозвался. Да мне не найти его. Сгинул в каком-то топике. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 20:07 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
kmawMonochromatique in-house разработка это что такое? Разработка ПО силами компании, для внутренних нужд. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 20:07 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
Monochromatiqueiscrafmпропущено... поэтому лада и выглядит как лада а не как ауди. Нужны именно гениальные архитекторы и гениальные программисты. Следить з сроками и бюджетом конечно может и добросовестный ПМ, гении возможно и не нужны У меня in-house разработка - я не убийцу facebook-а пишу. ценнность лицокниги не в программном коде, а самой идее, прежде всего. Если ты даже не знаешь кто за что отвечает в проекте, то какие "убийцы Facebook" могут рассматриваться в таком контексте. Думаю никто такого и не подумал ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 20:08 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
MonochromatiqueНужен средний предсказуемый результат. Меня ставить в рамки бесполезно, всегда найду обходной путь, когда для проекта нужно... А чтоб люди выполняли код - их этому тренировать надо: - Запросы пишутся в цикле... - Новые функции создавать только с благословения наставника... - Перед началом рабочего дня каждый послушник обязан прочитать молитву о кодировании Ну и регулярно испытывать послушников в вере. Кто отошел от веры в кодирование - выгонять из храма... Так наберется команда верных, предсказуемых послушников. Иначе от еретиков не избавиться. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 20:09 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
Monochromatiqueiscrafmпропущено... с чего ты взял что я тебе хамлю? Я сказал что ты не умеешь, без хамства. А вывод такой я сделал по твоим словам в этом топике и по твоему игнорированию простейшего вопроса пропущено... покажи проект, не игнорируй, если уж отозвался. Да мне не найти его. Сгинул в каком-то топике. здесь ничего не теряется, достаточно ключевое слово знать, но даже 8 страниц не тяжело просмотреть ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 20:11 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
MonochromatiqueТут вся тема о томпропущено... попытка реализовать микроменеджмент технически для компенсации эффектов отсутствия процессов и управления в целом, такой "микроменеджмент" вполне может даже позитивно существовать - см. те же прекоммит-хуки но это не есть сам процесс. это один из элементов инфраструктуры, созданной под процесс. "спуск интерфейсов" - вполне может быть даже частью системных требований. но речь не об интерфейсах реализованных/задекларированных в каком-то коде. PM пишет юнит с декларацией интерфейсов?.. архитектор, в целом, может. или тимлид. или сам программист, который должен эту задачу реализовать. пропущено... это отсутствие квалификации (исполнителя), отсутствие контроля, отсутствие работы с персоналом. где был код-ревью? где был руководитель, который (не)декомпозировал и назначил задачу? он что, не в курсе квалификации сотрудников? где был тимлид ,который должен быть в курсе квалификации тиммэйтов? если никто этим программистом (джуниором-студентом или почти сеньором с завышенным чсв и стремлением к абстракциям) не занимается, если у архитектора нет никаких мыслей, у руководителя нет ничего кроме двух с половиной абзацев в ворде - то что вы хотите? чтобы он все угадал? чтобы как в матрице "закачал себе управление вертолетом" и налабал запрос не в цикле? он же не умеет, если пишет запрос в цикле. В in-house разработке, особенно там, где производство ПО ДАЛЕКО не основная деятельность - косты режутся до состояния будет/не будет. Какое код-ревью, какая аналитика, какая проработка. Но качество ПОДАЙ. Дали мяч - фуячь, вот и всё ТЗ. С 1С-ом тоже в принципе можно придумать что сделать. Ведь цель - дать адекватную оценку результату за минимальное время. Разработать критерии и т.п. Ок. это понятно, я и не пытаюсь картины софт-контор расписывать. озвучены элементарные вещи уровня "чистить зубы", "мыть руки с мылом". в том и проблема. как это какой код-ревью? вы что, действительно фигачите сразу на продакшене? или неглядя выкладываете? и почему прозвучало "какая аналитика"? вроде ж был сбор требований, было "100-страничное ТЗ". авторДали мяч - фуячь, вот и всё ТЗ. вот! вот мы и вернулись к проблеме руководителя! вы все продолжаете быть программером. учитесь посылать нахер))) хитро, культурно, так чтобы все подумали что вы их хвалите, заботитесь об их здоровье и долголетии. ну и, собственно, это ж прозвучала констатация: все плохо, как все исправить, ничего не меняя. надо начинать. имхо начать имеет смысл: - с решения проблем постановки - то что выше озвучил про работу с требованиями; в процессе организации (постепенного проявления в сумбурных процессах) работы с требованиями должны потихоньку воспитываться заказчики. им нужно обозначать риски, трудозатраты, произносить фамилии тех, чьи задачи и насколько календарно должны быть сдвинуты чтобы сделать их "важную" говнокнопочку - все то что слышать не очень приятно. они не спрашивают - а вы все равно рассказывайте. и переспрашивайте, и просите подтверждения. мол, туповат я стал, да и забываю все. киньте в почту. плюс корректная оценка квалификации, адекватные назначения и декомпозиция+детализации требований - работу с уже написанным кодом - код ревью нужен обязательно, тем более что про квалификацию озвучено что в основном трудятся "бюджетные варианты"; обязательно нужен дев-полигон, механизмы/процедуры релиза; в процессе придумывания процедур релиза и во время внедрения кодревью должна умереть практика "програмеру юзер что-то говорит и на продакшене появляется какая-то нигде ранее не зафиксированная/не проанализированная/не учтенная при проектировании хрень" т.е. надо прекращать на вход подавать непонятно что и надо начинать смотреть что же там на выходе выдается серединка с инфраструктурой, архитектором, требованием подписей, отправкой на тренинги, обменом знаний и всякими внутренними вики, юнит-тесты и непрерывная интеграция подождут - дойдет и до них очередь. до кого-то может и не дойдет, но там дальше видно будет. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 20:18 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
MonochromatiqueРазработка ПО силами компании, для внутренних нужд. Всего лишь на 8 странице ТС родил что это внутренний проект. Ну ну. Ждемс продолжения банкета. (побежал за колой и чипсами) ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 20:18 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
MonochromatiqueОстаются прототипы? да, +опытный 1, 2 чела, которые их могут сделать быстро. не на пустом же месте разрабатываете ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 20:26 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
Тут вся тема о томи почему прозвучало "какая аналитика"? вроде ж был сбор требований, было "100-страничное ТЗ". 100-страничное ТЗ рождается на новом у крупном проекте. Какая-нибудь свистелка на полторы-две тыщи строк кода (1С) обходится без условностей. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 20:28 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
MonochromatiqueОстался вопрос. вопросов гораздо больше одного MonochromatiqueВ самом начале создается описание системы. Основные понятия, перечисление подсистем, картинки, схемы и прочее. Скажем так - вырастает это всё до сотни страниц. Это по лайту. Зачем это - заказчик хочет ПОНИМАТЬ, что он получит в итоге. Понять он может только текст. Причем околохудожественный. водопад вам нахрен не нужен 100 страниц - жесть я так понимаю речь не о моделях бизнес-процессов и алгоритмах, не о UML, IDEF0, EPC, т.е. "просто текст" по факту итоговых страниц может быть гораздо больше, вопрос не в количестве что надо: смотреть какие есть методологии, какие есть стандарты документации, принимать решения и вдавливать выбранное кусками в текущую реальность MonochromatiqueВ какие-то короткие сроки такой документ сделать нереально. Качественно сделать, я имею ввиду. Почему - писать можно что угодно. Какие-то системы могут быть несогласованы между собой, какие-то откровенно противоречить. Есть какие-то методики анализа/проверки, что модель описанная текстом - валидна? ээээ ммммм читать написанное? структурировать написанное чтобы его можно было читать? иметь разные уровни требований, а не "100 страниц текста"? MonochromatiqueПроверять программированием - долго. Остаются прототипы? не очень понятны оба пункта. проверять программирование-... если ничего не проверяли, то потом все сразу - да, долго. или у вас и здесь водопад? - программисты, вот вам 100 страниц! (через год) - пм, вот тебе 7000 юнитов, 200 000 строк! - пользователи, вот вам 300 форм и 1500 кнопок! - ...вашу мать, это че за херня? последний пункт - без вариантов! только так. прототипы - это скорее про управление ожиданиями. прототипировать можно на этапе сбора требований, на этапе проектирования, на этапе реализации. везде будут разные прототипы для разных людей (ну, может что-то и для одних и тех же но на разном уровне проектирования, с учетом разных подробностей). с учетом "пишем 100 страниц сначала" тоже теряет смысл и не очень понятно в какой момент и кому нужны эти прототипы. обратно смотреть на методологии и работу с требованиями ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 20:31 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
MonochromatiqueОстался вопрос. В самом начале создается описание системы. Основные понятия, перечисление подсистем, картинки, схемы и прочее. Скажем так - вырастает это всё до сотни страниц. Это по лайту. Зачем это - заказчик хочет ПОНИМАТЬ, что он получит в итоге. Понять он может только текст. Причем околохудожественный. В какие-то короткие сроки такой документ сделать нереально. Качественно сделать, я имею ввиду. Почему - писать можно что угодно. Какие-то системы могут быть несогласованы между собой, какие-то откровенно противоречить. Есть какие-то методики анализа/проверки, что модель описанная текстом - валидна? Проверять программированием - долго. Остаются прототипы? Вопрос не правильный. Для равноправных отношений Заказчик-Подрядчик такого не возникает. А вот когда Заказчик-хозяин, Подрядчик-внутренний наемный работник (in-house) и заказчик хочет звезду с неба - это бывает. Но ответ все равно кроется в заказчике. Если проект рисковый, надо его дробить по согласованию с заказчиком. Простые решения реализовывать и передавать в эксплуатацию. Там где остаются темные пятна, копать глубже, договариваться с заказчиком о прототипе, пилотном проекте и побывать, но не сдавать, пока есть сомнения. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 20:32 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
sereginsereginА вот когда Заказчик-хозяин тогда и говорить не о чем ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 20:33 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
Тут вся тема о томкак это какой код-ревью? вы что, действительно фигачите сразу на продакшене? или неглядя выкладываете? Разрабатывается отдельно. Тестируется отдельно (самим программистом). Максимум - попросит на форму посмотреть. Потом - в продакшен. Его код никто не смотрит. Считается, что он достаточно квалифицирован. Думаю, чтобы вникнуть в код 1С-ника потребуется чтолько же времени, чтобы его написать еще раз. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 20:34 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
Monochromatique100-страничное ТЗ рождается на новом у крупном проекте. Какая-нибудь свистелка на полторы-две тыщи строк кода (1С) обходится без условностей. - здравствуйте! почему мы лажаем? - вы не работаете с требованиями, с выдаваемым кодом, просматриваются пробелы в организации работы коллектива - это понятно. а почему мы лажаем? ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 20:36 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
а почему конторе другой не заказать? ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 20:37 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
sereginsereginЕсли проект рисковый, надо его дробить по согласованию с заказчиком. Простые решения реализовывать и передавать в эксплуатацию. Вот вот. Проект, который меня добил (закончился больше года назад) - предполагал ЗАМЕНУ существующей системы. То есть - объем функционала УЖЕ БЫЛ, и его надо было отрефакторить и дать замену. Так что реализовывать по кускам - не получалось. Плюс один из заказчиков занял позицию - "ну-ну посмотрим, что у вас получится." ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 20:39 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
MonochromatiqueТут вся тема о томкак это какой код-ревью? вы что, действительно фигачите сразу на продакшене? или неглядя выкладываете? Разрабатывается отдельно. Тестируется отдельно (самим программистом). Максимум - попросит на форму посмотреть. Потом - в продакшен. Его код никто не смотрит. Считается, что он достаточно квалифицирован. Думаю, чтобы вникнуть в код 1С-ника потребуется чтолько же времени, чтобы его написать еще раз. рано отправил, надо было это цитировать :)) ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 20:39 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
Тут вся тема о томчто надо: смотреть какие есть методологии, какие есть стандарты документации, принимать решения и вдавливать выбранное кусками в текущую реальность Ну для этого-я-как-бы-и-создал-тему. А в итоге - хорошую архитектуру создает хороший архитектор. TOGAF один раз всплыл да и всё на этом. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 20:44 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
kmawа почему конторе другой не заказать? Что не заказать? ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 20:44 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
MonochromatiqueДумаю, чтобы вникнуть в код 1С-ника потребуется чтолько же времени, чтобы его написать еще раз. давай без фантастики ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 20:49 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
MonochromatiqueТут вся тема о томчто надо: смотреть какие есть методологии, какие есть стандарты документации, принимать решения и вдавливать выбранное кусками в текущую реальность Ну для этого-я-как-бы-и-создал-тему. А в итоге - хорошую архитектуру создает хороший архитектор. TOGAF один раз всплыл да и всё на этом. понятно. об стену горох. дубль два: - здравствуйте! почему мы лажаем? - вы не работаете с требованиями, с выдаваемым кодом, просматриваются пробелы в организации работы коллектива - это понятно. а почему мы лажаем? добавочка: задаете вопросы, вам десять страниц описывают фактически имеющуюся у вас проблематику, а вы, видимо, не имея возможности принять критические по отношению к вашим навыкам замечания, в очередной раз называете всех трэшак-шапито, в итоге все остаются при своих. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 20:52 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
Злой БобрMonochromatiqueРазработка ПО силами компании, для внутренних нужд. Всего лишь на 8 странице ТС родил что это внутренний проект. Ну ну. Ждемс продолжения банкета. (побежал за колой и чипсами) ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 20:55 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
iscrafmMonochromatiqueДумаю, чтобы вникнуть в код 1С-ника потребуется чтолько же времени, чтобы его написать еще раз. давай без фантастики (Пожимая плечами) Давай. Исправь ошибку. Код: javascript 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14.
... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 20:55 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
Тут вся тема о томMonochromatique100-страничное ТЗ рождается на новом у крупном проекте. Какая-нибудь свистелка на полторы-две тыщи строк кода (1С) обходится без условностей. - здравствуйте! почему мы лажаем? - вы не работаете с требованиями, с выдаваемым кодом, просматриваются пробелы в организации работы коллектива - это понятно. а почему мы лажаем? ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 20:57 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
MonochromatiquesereginsereginЕсли проект рисковый, надо его дробить по согласованию с заказчиком. Простые решения реализовывать и передавать в эксплуатацию. Вот вот. Проект, который меня добил (закончился больше года назад) - предполагал ЗАМЕНУ существующей системы. То есть - объем функционала УЖЕ БЫЛ, и его надо было отрефакторить и дать замену. Так что реализовывать по кускам - не получалось. Плюс один из заказчиков занял позицию - "ну-ну посмотрим, что у вас получится." Функционал был известен, он работал - значит непротиворечивый. Чего тут проверять. Единственные 2 риска: 1. Переварит ли новая платформа старые алгоритмы и старую модель данных; 2. Уложиться в оговоренные сроки. Вопрос о том, что новая платформа должна предоставит преимущества перед старой и оправдать ожидания заказчика к рискам разработчика не относится. Это риски Заказчика. Гарантировать заказчику такое нельзя.... Правда, SAP дает такие гарантии, и иски в суд на них уже подавали. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 20:59 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
MonochromatiqueТут вся тема о томчто надо: смотреть какие есть методологии, какие есть стандарты документации, принимать решения и вдавливать выбранное кусками в текущую реальность Ну для этого-я-как-бы-и-создал-тему. А в итоге - хорошую архитектуру создает хороший архитектор. TOGAF один раз всплыл да и всё на этом. Тогаф для незрелых процессов разработки - как микроскоп для папуаса, он его все равно как каменный молоток использовать будет... ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 20:59 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
sereginsereginФункционал был известен, он работал - значит непротиворечивый. Абсолютно не тот вывод. Даже странный. Программист закрывал зарплату - вот такой функционал. И всех устраивало. Когда стали переделывать - оказалось - теперь чтобы закрыть ЗП сотрудникам нужно делать кучу движений + брать на себя ответственность. Ну и т.п. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 21:02 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
Тут вся тема о томдобавочка: задаете вопросы, вам десять страниц описывают фактически имеющуюся у вас проблематику, а вы, видимо, не имея возможности принять критические по отношению к вашим навыкам замечания, в очередной раз называете всех трэшак-шапито, в итоге все остаются при своих. Поправочка: Десять страниц здесь уже чего только не обсудили. Я можно сказать 19-летним фрилансером побыл, с 25-ти летним опытом. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 21:05 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
Тут вся тема о том что надо: смотреть какие есть методологии, какие есть стандарты документации, принимать решения Какие методологии/стандарты документации вы использовали на последнем крупном (субъективно) проекте? ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 21:07 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
sereginseregin1. Переварит ли новая платформа старые алгоритмы и старую модель данных; А об этом даже речи не было. Всё нужно было спроектировать заново. Иначе какой смысл? ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 21:08 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
Monochromatiqueiscrafmпропущено... давай без фантастики (Пожимая плечами) Давай. Исправь ошибку. Код: javascript 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14.
я же говорю: давай без фантастики. Как это вообще можно как текст программы рассматривать ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 21:16 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
А, ты в этом смысле... Ну так а чо- рабочие моменты. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 21:19 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
iscrafmя же говорю: давай без фантастики. Как это вообще можно как текст программы рассматривать наверное надо было сказать жестче: давай без фильмов ужасов ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 21:20 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
MonochromatiquesereginsereginФункционал был известен, он работал - значит непротиворечивый. Абсолютно не тот вывод. Даже странный. Программист закрывал зарплату - вот такой функционал. И всех устраивало. Когда стали переделывать - оказалось - теперь чтобы закрыть ЗП сотрудникам нужно делать кучу движений + брать на себя ответственность. Ну и т.п. Какие тут риски. Новые плюшки - риски Заказчика, что проект затянется. Неприятно что программист брал на себя ответственность за расчет зарплаты, но он раньше так делал. Ради реализации всего проекта, отдельное г.. приходится копипастить, а потом уже переписывать за отдельные деньги, это тоже реально оговаривать с заказчиком. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 21:23 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
MonochromatiqueТут вся тема о томдобавочка: задаете вопросы, вам десять страниц описывают фактически имеющуюся у вас проблематику, а вы, видимо, не имея возможности принять критические по отношению к вашим навыкам замечания, в очередной раз называете всех трэшак-шапито, в итоге все остаются при своих. Поправочка: Десять страниц здесь уже чего только не обсудили. Я можно сказать 19-летним фрилансером побыл, с 25-ти летним опытом. заметочка: ваше подсознание в очередной раз подсказало вам как обозначить всех вокруг неспособными вам помочь и возможно даже виноватыми в некоторых ваших трудностях на работе за возраст - оставим дублирую осмысленное: 18456072 абзац про долгофрилансеров (мне все-таки кажется, что он имеет отношение к делу) 18456239 про требования 18456471 всяко-разно 18456635 todo 18456716 нахрен водопад авторКакие методологии/стандарты документации вы использовали на последнем крупном (субъективно) проекте? каждому проекту - своя методология это основа применения методологий и обмена опыта по применению оных. в большинстве незакомплексованных компаний никакая конкретно методология не применяется в ее стерилизованном/академическом исполнении. разумный вариант: отсюда - то, оттуда - это, эта задача - XP, вот та хрень с финансами - водопад, с этими клоунами которые нихрена не знаю что хотят и везде нос суют попробуем применить ролевые штуки из скрама, для повседневной жизни циферки из канбана возьмем. и tdd по настроению. авторКакие методологии/стандарты документации вы использовали на последнем крупном или снова отголоски защитных реакций, мол, "сам-то ты чо"? я, на самом деле, рад если топик, так сказать, вдарил в болевую точку иначе бы болотце поглотило. но стартовые посты и последние реплики сильно подозрительно безвариантные. так-то мы все периодически неучами в разных вопросах оказываемся, в том числе, в самых, казалось бы, неожиданных. а если не дай бог профессиональный PM в этот топик заглянет!.. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 21:26 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
Код: plaintext
судьба и качество этого кода зашифрованы в нем самом ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 21:28 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
Monochromatique Я можно сказать 19-летним фрилансером побыл, с 25-ти летним опытом. Ну было б лет 10 опыта кодинга, то подобных вопросов не возникало. А так по ходу все совсем печально. Ежики плакали, кололись, но продолжали есть кактусы. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 21:35 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
Тут вся тема о томили снова отголоски защитных реакций, мол, "сам-то ты чо"? Навыдумывал ты что то. )) Объявись, ты кто? ))) Можно в личку. Тут вся тема о тома если не дай бог профессиональный PM в этот топик заглянет!.. При мне "профессиональный PM" так лажанул с приоритетным для себя проектом, что все до сих пор жмурятся. А ведь MBA, все дела. ))))) В сухом остатке, наверное так будет сформулировано правильно. Я не понимаю , как справляться с огромным потоком информации, который сваливается на тебя при начале нового проекта. Как справляться в лоб - без спец. инструментов . Величину я косвенно оценил количеством разработчиков - 10 человек. По коду - вопросов нет. В словосочетании " надо работать с требованиями " мне все слова понятны. В " архитектор отвечает за архитектуру " - тоже. Мне непонятно - как с ними работать, в каком виде - когда с одного конца поля - границы не то что не видно, а ты вообще не понимаешь - была ли она. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 22:44 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
И по теме - чистым PM-ом мне быть неинтересно, особенно, если он по сути отвечает за сроки/бюджет и гамбургеры. ))) Мне важно в первую очередь качество решения. PM-ом "у меня" будет мое руководство. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 22:46 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
MonochromatiqueПри мне "профессиональный PM" так лажанул с приоритетным для себя проектом, что все до сих пор жмурятся как? ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 22:50 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
iscrafmMonochromatiqueПри мне "профессиональный PM" так лажанул с приоритетным для себя проектом, что все до сих пор жмурятся как? Грубо говоря - с помпой взял на себя блок, сказал, что все утыри, и сейчас он за пол-года устроит дисней-ленд. Прошло два года, сменилось четыре прога - всё делают в EXCEL-е. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 23:02 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
MonochromatiqueИ по теме - чистым PM-ом мне быть неинтересно, особенно, если он по сути отвечает за сроки/бюджет и гамбургеры. Зря ты так. Хороший ПМ - это как бальзам на душу. За все время работы в Украине только одного такого видел. Разница ощущений работы с таким человеком - просто ни в какое сравнение не идет. Действительно приятно работать под руководством такого человека. MonochromatiqueГрубо говоря - с помпой взял на себя блок, сказал, что все утыри, и сейчас он за пол-года устроит дисней-ленд. Прошло два года, сменилось четыре прога - всё делают в EXCEL-е. Когда низы не могут, а верхи не хотят - без разницы кто будет пытаться нести флаг. Результат предопределен заранее. Тоже видел немало таких ситуаций. Увы, такова специфика бизнеса "по русски". Насчет экселя, лично я ничего против не имею. В Штатах бухгалтерию ведут в нем родимом. Опять же - глупые америкосы, закупили б у продвинутых 1С и все б у них было. Так что может оно и к лучшему. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 23:39 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
Злой БобрНасчет экселя, лично я ничего против не имею. В Штатах бухгалтерию ведут в нем родимом. Опять же - глупые америкосы, закупили б у продвинутых 1С и все б у них было. Как бы меня от 1С не воротило, я признаю - 1С - это TRUE RAD. с**а, стремительный как понос. Обсуждать плюсы и минусы можно долго. Но не в этой теме, наверное?? )))) ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2015, 23:59 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
Злой БобрЗря ты так. Хороший ПМ - это как бальзам на душу. Согласен. Возможны такие кейсы, когда твой босс ну настолько лапа, что ты ему детей доверишь, не то что после работы останешься. Лично я предпочитаю более просчитываемые варианты. ... |
|||
:
Нравится:
Не нравится:
|
|||
23.11.2015, 00:02 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
Злой БобрКогда низы не могут, а верхи не хотят Там не в этом дело. PM вообразил себя архитектором и улетел на Марс, забыв взять с собой собственно исполняющий персонал. Архитектором в самом общем варианте - я вам щаз расскажу, а вы послушайте. ... |
|||
:
Нравится:
Не нравится:
|
|||
23.11.2015, 00:04 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
MonochromatiqueОбсуждать плюсы и минусы можно долго. У 1С только один очевидный плюс - на порядок быстрее клепать формочки. Все. Больше я не смог придумать того чего нельзя сделать в экселе, а можно в 1С. И поверьте - я пытался, но никак. Так что связка экселя как клиента и мелкомягкого скуля в качестве БД очень даже жизнеспособна. Ну и не зря говорят: работает - не трогай. ... |
|||
:
Нравится:
Не нравится:
|
|||
23.11.2015, 00:13 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
Злой БобрВсе. Три буквы. СКД. ... |
|||
:
Нравится:
Не нравится:
|
|||
23.11.2015, 00:20 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
MonochromatiqueТри буквы. СКД. Неа. В экселе тоже есть отчеты. А для особо извращенных у мелкомягких есть MSAS. ... |
|||
:
Нравится:
Не нравится:
|
|||
23.11.2015, 00:29 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
Злой БобрMonochromatiqueТри буквы. СКД. Неа. В экселе тоже есть отчеты. А для особо извращенных у мелкомягких есть MSAS. Никто не переплюнет СКД. Если бы был настоящий аналог - я бы убил 1С в организации. Плевать даже на формы. ... |
|||
:
Нравится:
Не нравится:
|
|||
23.11.2015, 00:32 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
MonochromatiqueЗлой Бобрпропущено... Неа. В экселе тоже есть отчеты. А для особо извращенных у мелкомягких есть MSAS. Никто не переплюнет СКД. Если бы был настоящий аналог - я бы убил 1С в организации. Плевать даже на формы. а где искал? ... |
|||
:
Нравится:
Не нравится:
|
|||
23.11.2015, 00:38 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
MonochromatiqueНикто не переплюнет СКД. Если бы был настоящий аналог - я бы убил 1С в организации. Плевать даже на формы. MSAS как раз и есть то что бралось 1С за основу. Вся разница только в том что у мелкомягких MSAS это отдельный продукт за отдельные деньги. И работает он с реально очень большими объемами. Думаю таких объемов в 1С не наколотить и за 5 лет работы средней компании. Насчет качества реализации в 1С - промолчу. ... |
|||
:
Нравится:
Не нравится:
|
|||
23.11.2015, 00:41 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
Злой БобрMonochromatiqueНикто не переплюнет СКД. Если бы был настоящий аналог - я бы убил 1С в организации. Плевать даже на формы. MSAS как раз и есть то что бралось 1С за основу. Вся разница только в том что у мелкомягких MSAS это отдельный продукт за отдельные деньги. И работает он с реально очень большими объемами. Думаю таких объемов в 1С не наколотить и за 5 лет работы средней компании. Насчет качества реализации в 1С - промолчу. MSAS все же более "кубическая" система. ... |
|||
:
Нравится:
Не нравится:
|
|||
23.11.2015, 00:58 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
Monochromatique, !!! о вот вы то мне и нужны, расскажите чем все закончилось тут http://www.sql.ru/forum/1139359/nuzhno-razrabotat-web-service-mobilnoe-prilozhenie ? в какие сроки уложились? или текущая тема - как результат той? а я вам расскажу про серебряную пулю о том как вести разработку сложных систем силами 10 программистов :) ... |
|||
:
Нравится:
Не нравится:
|
|||
23.11.2015, 08:19 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
17-77Monochromatique, !!! о вот вы то мне и нужны, расскажите чем все закончилось тут http://www.sql.ru/forum/1139359/nuzhno-razrabotat-web-service-mobilnoe-prilozhenie ? в какие сроки уложились? или текущая тема - как результат той? а я вам расскажу про серебряную пулю о том как вести разработку сложных систем силами 10 программистов :) Ну, там всё ровно. В итоге 1.5 месяца и две недели мы (заказчики) гумозили. Так называемый PM бегал ко мне по каждому вопросу. За консультациями. Проект сдан и запущен. Это даже в резюме не включишь. ... |
|||
:
Нравится:
Не нравится:
|
|||
23.11.2015, 10:13 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
MonochromatiqueГрубо говоря - с помпой взял на себя блок, сказал, что все утыри, и сейчас он за пол-года устроит дисней-ленд. Прошло два года, сменилось четыре прога - всё делают в EXCEL-е. А вывод Вы сделали, что он плохой спец, доверять ему нельзя????? Проблема кроется не в личности, а в командной работе, в которой у Вас опыта маловато, а на 10 человек так совсем НЕТ. Деление задачи на блоки по предметной области работает для команды максимум 5 чел. На 10 человек требуется вертикальное разделение ответственности: - Аналитик и только аналитик работает с пользователями - Архитектор и только архитектор принимает решение о технологической платформе и разбиении системы на компоненты - Старший программист и отлько старший следит за кодом и остальными программистами Эта тройка независимых специалистов завязана друг на друге и не дает друг другу филонить. Ваша задача манипулировать ими для розжига рабочей обстановки и охлаждения разбушевавшегося пожара. С технической точки зрения, что нужно делать и в чем проблема Вы понимаете. Но с психологической Вам нужен помощник, опытный управленец. Найдите себе зама-администратора, желательно без опыта в ИТ ( чтоб Ваш авторитет не подавлял, и не на этом форуме). На 10 человек кто-то должен контролировать сроки работ, заниматься бумажно-оформительской работой и т.д. ... |
|||
:
Нравится:
Не нравится:
|
|||
23.11.2015, 10:15 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
sereginsereginMonochromatiqueГрубо говоря - с помпой взял на себя блок, сказал, что все утыри, и сейчас он за пол-года устроит дисней-ленд. Прошло два года, сменилось четыре прога - всё делают в EXCEL-е. А вывод Вы сделали, что он плохой спец, доверять ему нельзя????? Ну знаете, Серегин, никакой pmbok не нужен, чтобы отличить заваленный проект и запущенного. Собирался сделать программный блок. Блока нет. Всё стало еще хуже. Чего демагогию разводить?? Я (лично) руководил разработкой шести блоков и все запущены. Человек взял один и до сих пор жует. Он не плохой спец, он просто менеджер, который решил, что руководить разработкой - плевое дело. ... |
|||
:
Нравится:
Не нравится:
|
|||
23.11.2015, 10:27 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
sereginsereginПроблема кроется не в личности, а в командной работе, в которой у Вас опыта маловато, а на 10 человек так совсем НЕТ. Эта тройка независимых специалистов завязана друг на друге и не дает друг другу филонить. У меня вопрос не в 10-ти людях, а в сотне. Вот вы знаете, sereginseregin ... Когда я вижу у людей в резюме слово "архитектор" - я радуюсь, ну сейчас поболтаем!! Начинаю предметный разговор, но в ответ слышу то, что пытаются продать тут на протяжении уже 10 страниц. Скажу, распоряжусь, завязано, контроль... Ничего конкретного. Так не разрабатывают, так играют в разработку. В разработке нет места неформальному подходу с самого начала , а если на нём и получается выехать, то это просто сработал "запас прочности". Этого я уже нажрался. Сказала-мазала, подналяжем, парни. Любой слой должен выдавать на выходе ЧЕТКО очерченные артефакты, которые можно однозначно истолковывать. О них прозвучал вопрос в первом посте, о них не было сказано ни слова. Зато флуда на 10 страниц. Я наверное неправ (раз уж мы друг-друга не слышим), да и тему уже можно закончить. Вчера подумалось, что в Visual Studio есть необходимые мне инструменты. P.S. Свой список проектов я привел. Ни больше ни меньше. Любопытно бы было посмотреть на чей-нибудь еще. ... |
|||
:
Нравится:
Не нравится:
|
|||
23.11.2015, 11:06 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
MonochromatiqueЯ (лично) руководил разработкой шести блоков и все запущены. Человек взял один и до сих пор жует. это совершенно не показатель. Можно сделать шесть банальных по логике приложений но застрять на одном с нетривиальной логикой. Ты все время какие-то численные показатели приводишь совершенно не там, где они могут играть хоть какое-то значение. Какие-то 2000 документов, шесть блоков... При приведении таких абстракций всегда нужно указывать что это за блоки и документы. ... |
|||
:
Нравится:
Не нравится:
|
|||
23.11.2015, 11:10 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
Monochromatique, С самого начала Вы правильно осознали проблему ГОРИЗОНТАЛЬНОГО ДЕЛЕГИРОВАНИЯ ПОЛНОМОЧИЙ: "Если 100 листов ТЗ разбить на блоки и поручить каждый блок реализовывать и внедрять отдельному специалисту, где гарантия, что корабыль в целом поплывет?" Но никак не можете понять, что существует (в любой классической книге про МЕНЕДЖМЕНТ описывается) ВЕРТИКАЛЬНОЕ ДЕЛЕГИРОВАНИЯ ПОЛНОМОЧИЙ: - Должен быть специалист, который будет формировать и исправлять ТЗ целиком - Должен быть другой специалист, который сформулирует техническое решение на все ТЗ целиком - Должен быть третий специалист, который реализует в соответсвии с техническим решением это ТЗ целиком Больше сказать нечего, спасибо за внимание! ... |
|||
:
Нравится:
Не нравится:
|
|||
23.11.2015, 11:23 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
MonochromatiquesereginsereginПроблема кроется не в личности, а в командной работе, в которой у Вас опыта маловато, а на 10 человек так совсем НЕТ. Эта тройка независимых специалистов завязана друг на друге и не дает друг другу филонить. У меня вопрос не в 10-ти людях, а в сотне. Вот вы знаете, sereginseregin ... Когда я вижу у людей в резюме слово "архитектор" - я радуюсь, ну сейчас поболтаем!! Начинаю предметный разговор, но в ответ слышу то, что пытаются продать тут на протяжении уже 10 страниц. Скажу, распоряжусь, завязано, контроль... Ничего конкретного. Так не разрабатывают, так играют в разработку. В разработке нет места неформальному подходу с самого начала , а если на нём и получается выехать, то это просто сработал "запас прочности". Этого я уже нажрался. Сказала-мазала, подналяжем, парни. Любой слой должен выдавать на выходе ЧЕТКО очерченные артефакты, которые можно однозначно истолковывать. О них прозвучал вопрос в первом посте, о них не было сказано ни слова. Зато флуда на 10 страниц. Я наверное неправ (раз уж мы друг-друга не слышим), да и тему уже можно закончить. Вчера подумалось, что в Visual Studio есть необходимые мне инструменты. P.S. Свой список проектов я привел. Ни больше ни меньше. Любопытно бы было посмотреть на чей-нибудь еще. во, вернулся стиль первых постов. набор слов собранный в странные предложения. ... |
|||
:
Нравится:
Не нравится:
|
|||
23.11.2015, 11:26 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
MonochromatiqueНачинаю предметный разговор, но в ответ слышу то, что пытаются продать тут на протяжении уже 10 страниц. ты что-то перепутал. Тебе предметно отвечено в начале топика, а после этого 10 страниц именно от тебя всякой каши про какие-то абстрактные 2000 документов и 6 блоков. MonochromatiqueСвой список проектов я привел. Ни больше ни меньше. Любопытно бы было посмотреть на чей-нибудь еще. ты привел никому не известные названия ... |
|||
:
Нравится:
Не нравится:
|
|||
23.11.2015, 11:35 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
MonochromatiqueP.S. Свой список проектов я привел. Ни больше ни меньше. Любопытно бы было посмотреть на чей-нибудь еще. Ну так заходите на job сайты и смотрите в анкетах. Тут в основном народ не меряется размерами. Хотя иногда и такое бывает. ... |
|||
:
Нравится:
Не нравится:
|
|||
23.11.2015, 11:39 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
Злой БобрНу так заходите на job сайты и смотрите в анкетах как можно на других сайтах увидеть информацию по анонимам на этом ресурсе? ... |
|||
:
Нравится:
Не нравится:
|
|||
23.11.2015, 11:51 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
По поводу разработки сложной системы есть методологии внедрения например - AIM. ... |
|||
:
Нравится:
Не нравится:
|
|||
23.11.2015, 12:45 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
dmitry1000По поводу разработки сложной системы есть методологии внедрения например - AIM. а также целая когорта подобных ... |
|||
:
Нравится:
Не нравится:
|
|||
23.11.2015, 12:58 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
dmitry1000, основная проблема в постановке конкретных вопросов, которые ТС уже 10 страниц не может сформировать. А методологий хватает, в том числе и тех, которые помогают сформировать условия задачи прежде всего ... |
|||
:
Нравится:
Не нравится:
|
|||
23.11.2015, 13:02 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
MonochromatiqueСкажем - группой 10 программистов. Считаем что: 1. Что количество программистов адекватно задаче. (+/-) 2. Что пользовательские истории зафиксированы. Чего хочется: Предсказуемость разработки. Оценка состояния проекта, в идеале с шагом в день. Возможность быстро спуститься к самым мелким деталям и оценить их соответствие проектной документации. Ну, проектной документации - громко сказано. Что имеем: Первоначальное описание решения - является неким упражнением для писательского таланта. Ценность теряет ОЧЕНЬ быстро, потому что разработка очень быстро идет в сторону. Зачастую из-за: 1. Пользователи говорят одно, думают другое, а нужно третье. 2. Архитектор перемудрил и решил сделать космолет, который должен рыть бассейны в условиях сверхгравитации и нехватки естественных осадков. 3. Программист неправильно понял, что нужно сделать - и убил три дня на неприменимую ерунду. 4. Программист решил написать свой мега-фреймворк, на который убил 95% времени, результата не достигнув. Вопросы: 1. Каким образом получить исчерпывающее описание проекта, которое не придется выбрасывать в мусорку через месяц? 2. Каким образом технически запретить уходить в сторону? Штуки типа WWF? Быстрые прототипы? Лично я склоняюсь к прототипам. Теперь к коду. Следующая проблема - в системах типа 1С - любой программист имеет доступ к любой части кода. Сам себе архитектор. Когда их 10 человек - уследить за всеми нереально и трешовый код/решения потихоньку берут верх. В .NET/JAVA я представляю что можно сделать - закрыть сборку с моделями и создать нужные интерфейсы, которые потом последовательно реализовывать, но что делать в той же 1С?? В 1С один кодер намутит треш, другой нагородит зауми, пытаясь сделать универсальную приладу, которая нужна всем (никому). Иными словами - какой процесс обеспечит: 1. Разумное количество слоев управления разработкой (истории, требования,UI ,код ) 2. Качество артефактов каждого слоя. Оно должно быть таким, чтобы с каждым низлежащим слоем мог работать специалист, не вовлеченный в этот проект прежде. 3. Каждый артефакт должен быть валидным и не противоречивым! Код понятно - он хотя бы должен работать, а как быть с описанием какого-то процесса?? Как убедиться, что процесс выдает ровно тот результат, который сможет принять на входе следующий процесс? Нужны четкие тиски, но какие тиски у Вордовского документа? Бумага всё стерпит. Нужно качество превратить в количество. Читаю истории, в которых над проектами трудятся люди из разных стран и часовых поясов - как их координировать? Тогда как собственные сотрудники без стояния за спиной сразу же стремятся расползтись в стороны. Как это может выглядеть? 1С case Обычно есть система, которая уже живет несколько лет. Технологии ушли вперед, груз существующих проблем стопорит бизнес-процессы. Все в депрессии. Принято решение переписать всё нафиг на современных технологиях. (Тут всё начинается). Бесконечные совещания, на которых пользователи разных рангов рассказывают о своих фантазиях. Всё, что снилось - всё вываливают. Объяснения куцые, пальцы показывают замысловатые фигуры. Составляется описание нового решения, страниц так на сто. Несмотря на картинки - его никто не читает, и также никто возражений не имеет. Начинается разработка. По грубой оценке - к оценке привлекаются n-программистов. Начинается разработка. Появляются первые результаты. Первые показы. Пользователи в недоумении - нужно же было по другому. Начинаются переделки/доработки, причем каждый программист делает это "втихую", потому как так сказала Лена-менеджер. Ну и в итоге разработка приобретает хаотичный характер. Не думаю, что в случае технологий вида JAVA/.NET картина принципиально другая. Единственно - больше времени нужно потратить на проектирование интерфейсов, но и программист-кодер в сторону не уйдёт. Что НЕ хотелось бы тут обсуждать: 1. UI 2. UX 3. Назначенным со стороны клиента менеджерам - плевать на внедрение. 4. Назначенные со стороны клиента менеджеры - некомпетентны.У нас к примеру разработка ведётся в группах (артелях). Последние сами решают какие задачи им взять из роадмапа, сами их анализируют, оценивают, готовят прототипы, проводят UX тестирование, обкладывают метриками, тестируют. ... |
|||
:
Нравится:
Не нравится:
|
|||
23.11.2015, 13:14 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
skyANAУ нас к примеру разработка ведётся в группах (артелях). Последние сами решают какие задачи им взять из роадмапа, сами их анализируют, оценивают, готовят прототипы, проводят UX тестирование, обкладывают метриками, тестируют. так делается, но не при создании новой системы. Именно в таких случаях живучий роадмап из которого каждый может забрать какой-то объем. support так живет в основном ... |
|||
:
Нравится:
Не нравится:
|
|||
23.11.2015, 13:21 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
iscrafmskyANAУ нас к примеру разработка ведётся в группах (артелях). Последние сами решают какие задачи им взять из роадмапа, сами их анализируют, оценивают, готовят прототипы, проводят UX тестирование, обкладывают метриками, тестируют. так делается, но не при создании новой системыНу не знаю. Мы успешно выпускаем новые фичи. ... |
|||
:
Нравится:
Не нравится:
|
|||
23.11.2015, 13:37 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
skyANA, У нас аналогично. Есть список задач, дата до которой нужно сделать, цена. Каждый час цена меняется, т.е. повышается на определенный шаг. Кто первым взял тот и банкует. Но если вдруг не уложишся в срок - ... . Никто никому на поворотах не заносит. Каждый сам понимает меру ответственности. Если что непонятно - всегда можно уточнить у менеджера (письменно). По скайпу можно связаться только когда сроки уже поджимают и ты не можешь понять то что тебе ответили. Такое бывает крайне редко. Но согласен - это не создание с нуля, а поддержка и развитие уже существующего. Хотя такой подход вполне можно распространить на программистов, когда есть готовый каркас. Все зависит от того кто рулит и по каким правилам играют. Нельзя все сваливать на 1-2 человек. ... |
|||
:
Нравится:
Не нравится:
|
|||
23.11.2015, 13:45 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
Злой Бобр, не сказал бы, что ресь ппрям про "с нуля". MonochromatiqueОбычно есть система, которая уже живет несколько лет. Технологии ушли вперед, груз существующих проблем стопорит бизнес-процессы. Все в депрессии. Принято решение переписать всё нафиг на современных технологиях. Бизнес-процессы выстроены, надо их улучшить. ... |
|||
:
Нравится:
Не нравится:
|
|||
23.11.2015, 13:52 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
skyANAiscrafmпропущено... так делается, но не при создании новой системыНу не знаю. Мы успешно выпускаем новые фичи. новые фичи, но не система с нуля. Хотя может и у ТС тоже об этом ... |
|||
:
Нравится:
Не нравится:
|
|||
23.11.2015, 14:51 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
Monochromatique... 1. Разумное количество слоев управления разработкой (истории, требования,UI ,код ) .... Читаю истории, в которых над проектами трудятся люди из разных стран и часовых поясов - как их координировать? Тогда как собственные сотрудники без стояния за спиной сразу же стремятся расползтись в стороны. Да хоть на марсе... Назначить координаторов (менеджеров, администраторов, специалистов, чиновников) которые своими руками, без автоматизации будут следить за каждым слоем разработки. Выделите из своих артелей способных: Кто удачно с пользователями работает, пусть для всех артелей собирают и формулируют непротиворечивые истории и требования; У кого фундаментальные технологические идеи, пусть формируют спецификации к модулям и функциям, и следят чтоб в артелях лишнего не писали; Кто код правильный пишет, пусть курирует код по всем артелям, чтоб правильный был MonochromatiqueКак это может выглядеть? 1С case К 1C это не относится, это общий подход к управлению сложными проектами Если и сейчас не понятно, то ищите проекты с маленьким ТЗ, этот не ваш! ... |
|||
:
Нравится:
Не нравится:
|
|||
23.11.2015, 14:57 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
sereginsereginВыделите из своих артелей способных круговая порука основа всего? ... |
|||
:
Нравится:
Не нравится:
|
|||
23.11.2015, 15:03 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
MonochromatiqueУ меня был неудачный опыт - программист с порученной задачей не справился. То есть - на тестовом объеме (и на реальных людях) всё работало, а на реальных объёмах всё ложилось. Это как? Что тогда такое "тестовые объемы"? Какая заложена средняя и пиковая нагрузка в проекте, если на реальных объемах все легло? Как тестировали, если тесты должны были показать пиковые значения. Скорее всего никто ничего реально не тестировал, сделали только видимость тестов. Или в ТЗ пропустили пару нулей в объемах? Не могу судить, не зная подробностей, но постановщик скорее тут в одной упряжке с проггером. ... |
|||
:
Нравится:
Не нравится:
|
|||
23.11.2015, 21:30 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
По теме сабжа. У вас кто пишет ТЗ и кто оценку ТЗ делает? Сколько времени пишите ТЗ? Кто, как и когда выставляет сроки по проекту? Контрольные точки в каком временном диапазоне? Вы как я понял контролировать прогеров хотите ежедневно, по вашим постам. Ну введите оплату по строчкам кода. Это разве решение? Смысл контролировать прогеров, смотреть ежедневные интерации? Есть определенный блок/модуль, есть сроки (с контрольными точками) и ответственность. А то можно дойти до контроля времени поставив считыватель на туалеты. PS: ответьте пож-та на вопросы. ... |
|||
:
Нравится:
Не нравится:
|
|||
23.11.2015, 22:21 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
MonochromatiqueiscrafmДать задание архитектору подготовить исчерпывающее описание проекта И еще такая проблема. Если описывать проект в ворде (текст), то нет никаких сдерживающих факторов, что к 50-той странице проект не начнет отрицать сам себя. Такой вот выверт. Только на 50-ой странице это будет непонятно. Есть документ - Концепция (2 страницы). С него вообще, проект начинается. ... |
|||
:
Нравится:
Не нравится:
|
|||
24.11.2015, 13:15 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
Monochromatique1. На какие этапы участники форума бьют задачи. Задачи уровня "10 человек - полгода". Стараемся не дробить работы на подзадачи продолжительностью меньше 6-8 часов. 2. Какие артефакты выдает каждый этап? В каком виде?Можете описать размеры этапов? 3. Кто и как решает, что артефакт валидный. Ну то есть не - "я почитал, вроде нормально".Большую часть работ принимает архитектор (функционал, проектную документацию). Когда у меня были относительно небольшие проекты (не 5-8 человек) я совместно с архитекторами принимал участие практически во всех встречах с заказчиком (на которых формируются ФТ, обсуждаются промежуточные версии ЧТЗ, выполняется демонстрация разработанного функционала и пр.), а так же старался принимать участие в написании ЧТЗ (по некоторым этапам писал сам, архитекторы потом вычитывали и корректировали в части тонкостей, по некоторым писали архитекторы, а я вычитывал и корректировал). Таким образом имел представление о том, чего ждет заказчик и как это будет делаться. Лично мне управлять такими проектами было спокойнее, т.к. мог при необходимости быстро погрузиться в задачу. Когда число одновременно выполняемых проектов выросло, такие элементы микро менеджмента мне уже не под силу, просто времени нет. Приемка практически полностью в руках архитекторов, а это, конечно риски (из 8 архитекторов доверить полностью я могу только одному, но он просто безумно перегружен т.к. много времени тратит на проверку работы выполненной подчиненными). Сейчас основным способом управления качеством для меня является финансовая мотивация. Кто хорошо и быстро работает - получает больше. Фактические трудозатраты заставляю списывать каждый день (по факту не каждый день удается добиться 100% списания, но все не так плохо), планы актуализирую несколько раз в неделю. Тут главное выбрать для себя удобный и эффективный инструмент ведения проектного учета. ... |
|||
:
Нравится:
Не нравится:
|
|||
24.11.2015, 16:53 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
user1cМожете описать размеры этапов? Ну вот например решение для транспортной компании. Решение начиналось от системы учета приёма/ротации водителей на работу, и заканчивалось удержанием из зарплаты перерасходов на сотовую связь. Что у нас в промежутке... Учет ТС, учет доп. компектации, выпуск машин в рейс, сопроводительная документация, извещение заинтересованных лиц по СМС о предстоящем рейсе, учет всевозможных денег, сопровождение машины в рейсе, телефония,звонок робота голосом,связь с водителями, СМС, фиксация событий, обработка сигнала с GPS (не 1С), расчет оптимальных маршрутов (не 1С), расчет отклонений, прогноз воровства топлива, импорт данных отовсюду(ОПСОСЫ, заправки...), нормирование ресурсов, расчет ЗП водителей (жесть)... Плюс формализация передачи инфы между отделами, учет склада запчастей... Сопряжение с другими КИС и миллион отчетов. Одна маршрутизация (расчет маршуртов и их влияние на ЗП) вводила такую туеву хучу понятий, что было решительно неясно - как это вообще взлетит. Так вот. Выслушать всех юзеров/носителей знаний и зафиксировать их бубнеж (диктофон/пометки) - это _один_ этап. Переварить это, и перевести на бумагу в более-менее удобном виде - _второй_ этап. Третий - создать общее описание системы, чтобы заказчик понял в общих чертах - что он получить в итоге (те самые 100 страниц) - третий этап. На самом деле - 100 страниц - это была попытка описать некоторые функции ядра и нескольких спец. подсистем, такие, например как события и их маршрутизация/реакция системы на события. И да - это _третий_ этап. И вот на этом третьем этапе - как не чувствовалось, что вся описанная система в принципе консистентна. Ну а потом прототипирование интерфейсов перемежку с кодингом, промежуточные показы, сдачи, инструкции и т.д. Там уже не до протоколов было. Каждая задача хоть и была по максимуму обособлена - но зачастую сильно влияла на другую. Как-то так. ... |
|||
:
Нравится:
Не нравится:
|
|||
24.11.2015, 17:34 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
MonochromatiqueВыслушать всех юзеров/носителей знаний и зафиксировать их бубнеж (диктофон/пометки) - это _один_ этап. Переварить это, и перевести на бумагу в более-менее удобном виде - _второй_ этап. Третий - создать общее описание системы, чтобы заказчик понял в общих чертах - что он получить в итоге (те самые 100 страниц) - третий этап. На самом деле - 100 страниц - это была попытка описать некоторые функции ядра и нескольких спец. подсистем, такие, например как события и их маршрутизация/реакция системы на события. И да - это _третий_ этап. И вот на этом третьем этапе - как не чувствовалось, что вся описанная система в принципе консистентна. а ты думаешь архитектором так просто быть? ... |
|||
:
Нравится:
Не нравится:
|
|||
24.11.2015, 17:39 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
Monochromatique, А что с этим проектом решили? Красное и Белое, Бристоль, Магнит - на чем они работают? ... |
|||
:
Нравится:
Не нравится:
|
|||
24.11.2015, 18:36 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
Monochromatique, И сколько времени у Вас на все это есть? Мне кажется пока такую систему в целом спроектирует и разработает команда из 10 человек, все бизнес процессы успеют существенно видоизмениться. ... |
|||
:
Нравится:
Не нравится:
|
|||
24.11.2015, 19:17 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
user1cMonochromatique, И сколько времени у Вас на все это есть? Мне кажется пока такую систему в целом спроектирует и разработает команда из 10 человек, все бизнес процессы успеют существенно видоизмениться. да ладна, в 1С есть готовые конфигурации для этого. там просто надо внедрить/допилить ... |
|||
:
Нравится:
Не нравится:
|
|||
24.11.2015, 20:04 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
kmawда ладна, в 1С есть готовые конфигурации для этого. там просто надо внедрить/допилить Я б сказал в большей или меньшей степени изменить процессы под конфигурацию. Т.к. у многих все делается через Ж. Зотя и в конфигурациях далеко не факт что все будет, и то что будет не факт что работает правильно. При любом подходе работы будет много. У знакомых SAP внедряли больше 3-х лет. И это именно внедрение а не попил бабла. Те кто говорят что за полгода сделают - явно с головой не дружат. ... |
|||
:
Нравится:
Не нравится:
|
|||
24.11.2015, 20:11 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
Злой БобрПри любом подходе работы будет много. У знакомых SAP внедряли больше 3-х лет. И это именно внедрение а не попил бабла. в течении года иногда все очень меняется кардинально. Злой БобрТе кто говорят что за полгода сделают - явно с головой не дружат. есть и другой мир, он тебе просто не известен. Немного другие принципы построения систем применяются. И да, за полгода делается. ... |
|||
:
Нравится:
Не нравится:
|
|||
24.11.2015, 20:35 |
|
Как правильно вести сложную разработку?
|
|||
---|---|---|---|
#18+
Monochromatique, я все это делал следующим образом: Т 1. была идея проекта, рп знал куда надо придти и объяснял мне хотелки на абстрактном уровне 2. БА писал пояснительные записки к функциям, потом это стало документом для проверки и оплаты клиентом 3. был я и команда до 7 программистов + тестировщик(и) 4. я сделал каркас и заложил те или иные подходы, т.е. для программистов часть работы была в виде конструктора, ui вообще делали по шаблону копи-паст с переименованием и дополнениями 5. каждую фичу я обдумывал - как ее примерно делать, риски, что понадобиться доделать в архитектуре и т.п. я же назначал задачи в жире, рассказывал про точки интеграции и где читать более подробное описание того, что нам надо (взаимодействие с БА), если я видел что часть работ пересекается - я говорил паре программистов, что они делают смежную задачу, описывал примерные места дублирования кода и просил общаться между собой, чтоб согласовать код и результат 6. я делал ежедневное ревью кода за всеми программистами, писал todo, объяснял что не так и как надо или лучше - в итоге я всегда был в курсе всего проекта - я знал каждый закоулок, на какой стадии и когда примерно закончим 7. вместе с БА я делал функциональное тестирование - на одном экране тз, на другом код и идем сверять, косяки записываем, объясняем, исправляем 8. писал quick start guide и описание архитектуры и ее возможностей фактически это ручное управление и контроль и не факт, что будет работать в командах более 10 человек, но мне нравилось что команда была продолжением меня ... |
|||
:
Нравится:
Не нравится:
|
|||
25.11.2015, 14:20 |
|
|
start [/forum/topic.php?all=1&fid=33&tid=1547416]: |
0ms |
get settings: |
10ms |
get forum list: |
13ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
48ms |
get topic data: |
11ms |
get forum data: |
3ms |
get page messages: |
205ms |
get tp. blocked users: |
1ms |
others: | 13ms |
total: | 310ms |
0 / 0 |