> Короче, чтобы в 5-10 минут уложиться, надо мегагуру быть с как минимум 10 лет опытом и знанием всех кривых вариантов бизнес-процессов во всех кривых позах.
Не веришь? Ну и пусть, не буду спорить, пилите Шура, пилите...
Только вот я конечно дико извиняюсь, но остаюсь при мнении, что это, ну, в общем, глупость, снова делать одну и ту же работу (изучать БП кассира на натуре), которую до нас уже сделали тысячу раз, и ещё молодых учить делать так же. Остаюсь при мнении, что бы учиться по учебникам не нужно быть мегакенгуру.
Здравствуйте, Gaperton, Вы писали:
G>Короче, чтобы в 5-10 минут уложиться, надо мегагуру быть с как минимум 10 лет опытом и знанием всех кривых вариантов бизнес-процессов во всех кривых позах.
Мне кажется, одного опыта мало, ограниченность человека и развитие процессов позволяют очень большим фирмам достаточно долго разрабатывать, знакомые всем нам программные продукты.
Здравствуйте, grosborn, Вы писали:
>> Короче, чтобы в 5-10 минут уложиться, надо мегагуру быть с как минимум 10 лет опытом и знанием всех кривых вариантов бизнес-процессов во всех кривых позах.
G>Не веришь? Ну и пусть, не буду спорить, пилите Шура, пилите... G>Только вот я конечно дико извиняюсь, но остаюсь при мнении, что это, ну, в общем, глупость, снова делать одну и ту же работу (изучать БП кассира на натуре), которую до нас уже сделали тысячу раз, и ещё молодых учить делать так же. Остаюсь при мнении, что бы учиться по учебникам не нужно быть мегакенгуру.
Слушай, про кассира реально верю, и более того — не могу припомнить у себя ситуации, когда я после визита к кассиру не задавался бы вопросом — зачем я вообще к нему приходил . И с тем, что учиться по учебникам надо — на 100% согласен. А вот про бухгалтера — точно знаю, что перетереть с ним насчет интеграции или хотя бы импорта проводок придется. Они такие выдумщики бывают на самом деле, эти бухгалтера.
И взять даже казалось бы типовые схемы работы торговых предприятий — если они дают товар под реализацию — то они тоже могут оказаться редкостными выдумщиками. При оптовой торговле — может различаться от компании к компании процесс отгрузки. Может также быть нестандартной схема учета затрат при рассчете себестоимости в оперативном учете — это не смотря на то, что есть FIFO, LIFO и средневзвешенная. Скажем, если мы торгуем товаром со сроком годности — в аптеке, например, там может применяться экзотическая версия LIFO. Может отличаться схема резервирования и закупки товаров — они бывают экзотическими. Есть в природе дикие гибриды кредитных схем и схем под реализацию.
Откуда вам знать, что за фасадом знакомых слов не кроются нестандартные выдумки? Я вот страховался и всегда восстанавливал фактический процесс. Если клиент делает вам почасовую оплату — он не поймет, почему должен за переделку платить. Нервничать начинает. Лохом консультанта считать.
Здравствуйте, vpedak, Вы писали:
V>Здравствуйте, Gaperton, Вы писали:
G>> Тогда я как решал — либо идти в полноценные бизнес-аналитики на фулл-тайм, занявшись реорганизацией БП и консалтингом профессионально, или в хардкорную разработку — хотелось на крупных заказах или в крупной девелоперской конторе поработать, где порядок, чтоб хоть посмотреть на него, какой он. Ушел в результате в разработку.
V>А можно вопрос? Ну и как нашелся порядок? Я серьезно, просто у меня такое впечатление, что порядка нигде нет в разработке.
Гхм. С ним ведь, с порядком оказалось как. Думаешь по ходу дела, что бардак, а потом вспоминаешь через несколько лет — и доходит — так то ж порядок был, блин . Я серьезно, именно так .
V>Вот недавно опять после хорошего обсуждения договорились сформулировать требования для одной фичи, выделили ответственного чтобы он это сделал, а в результате для разработки мне пришло 3 разных варианта (один от этого человека и парочка от руководства) Фичка конечно маленькая, это я так, для примера... Большие вещи мы все-таки стараемся специфицировать более внятно. Да и я уже умею минимизировать подобные проблемы
Хо-хо. Это управление требованиями, с этим я еще порядка своими глазами не видал. Очень хочу. Природа порядка здесь — требования должны быть трассируемы. Другими словами, вы должны иметь возможность для каждой фичи установить причину ее появления, и ее критичность, что позволит вам управлять ее приоритетом по ходу проекта. Если эта связь отслеживается документально — все хорошо. Если после согласования требований при начале разработки никто уже не помнит, откуда фича взялась, и чем продиктована необходимость в ней — вы лишены возможности сделать репланнинг по ходу проекта, чтобы уложить его в сроки.
И вот еще какой момент. Если вы не понимаете, как это устроить нормальным человеческим образом — на пальцах, в уме, или простых текстовых документах, то и тулзы управления требованиями вам не помогут.
Мы для начала разработали новые формы проектных документов (пара недель назад), по которым реально проследить трассировку. Что позволяет выполнять формальные инспекции — и вылавливать ошибки в технических требованиях, переходу к ним от маркетинговых, и переходе от техтребований к реализации до старта самой реализации. Формы просты в заполнении, и допускают кросспроверки на полноту, непротиворечивость, и соответствие. Вот такое видение порядка. Посмотрим, как будет работать.
Первые результаты уже есть — при изменении формы документа в одном из текущих проектов на новую мы серьезно уточнили технические требования, и доказали их соответствие сценариям применения. После чего — отправили на повторную проверку (предыдущие требования уже успешно прошли проверку), и повторная проверка показала огромную кучу неточностей в сценариях, и как следствие — пробелы в техтребованиях (аукнулось бы стрессовой ситуацией на кодровании — мы бы их нашли позже, в середине проекта, и перепугались бы). Это сильно расстроило автора документа — он сказал так: "почему так много замечаний — ведь это лучшее и самое понятное ТЗ, которое мы когда либо делали — неужели документу стало от этого хуже?!". А ему ответили: "Вот, именно потому, что документ стал лучше, мы и смогли за столь короткое время найти в нем так много ошибок — они теперь стали как на ладони!"
V>Но судя по общению с окружающими, большинство компаний софрверных в России под менеджментом требований подразумевает наличие какого-либо документа который хоть как-то описывает что надо сделать и самое главное, что его конечно никто не синхронизирует с действительностью
Ну, одно только наличие документов — это разумеется не порядок. Это то, что в этой конфе все называют "ватерфолом". Типа, пишешь документы — вотерфолишь значит потихоньку. На самом деле суть вотерфола в другом — он основан на посылке, что раннее обнаружение ошибок удешевляет разработку. Для этого документы и пишут — чтобы их проверкой можно было найти ошибки тогда, когда кода еще нет. Во многих ли конторах практикуют формальные инспекции документов? То-то же. Нафига их писать, если их не проверять. Эдак их дешевле вообще не писать — результат тот же.
А говорят — вотерфол, вотерфол во всем виноват. Уметь надо вотерфолить, это ж не на броневик взбираться, как в XP. И не лобовая кавалерийская атака первой конной со сверкающими отточенными шашками наголо, как в agile. Истинный вотерфол — это вдумчивое стратегическое планирование, напряженная штабная работа, шуршание карт, тихие переговоры насупленных офицеров и генералов, математически выверенный дебют, гамбит, и эндшпиль. Это эшелонированная оборона и молниеносные десанты, прорывы танковыми клиньями с флангов и заходом противнику в тыл! Вот каков истинный вотерфол — он нетороплив, как падающий осенний лист, и внезапен, как удар весеннего грома. Выдержка — оборотная сторона решительности. Хао. Я все сказал.
> Слушай, про кассира реально верю, и более того — не могу припомнить у себя ситуации, когда я после визита к кассиру не задавался бы вопросом — зачем я вообще к нему приходил . И с тем, что учиться по учебникам надо — на 100% согласен. А вот про бухгалтера — точно знаю, что перетереть с ним насчет интеграции или хотя бы импорта проводок придется. Они такие выдумщики бывают на самом деле, эти бухгалтера.
Когда разберешься с этими выдумщиками поближе, выясняется, что выдумывают они тогда, когда не знают, как сделать правильно.
К сожалению, в ближайшее время не смогу ответить развернуто, на своих примерах. Пиковая нагрузка. Но если ты приведешь конкретный пример, совсем не нужно его подробно описывать, просто укажи суть, я тебе скажу где там ошибка. Пример с приходованием на виртуальный склад не понятен, поскольку ты не указал, зачем они так сделали. Могу предположить, что с компьютером умела работать только одна тетка, и могла оприходовать только на один склад
Здравствуйте, grosborn, Вы писали:
>> Слушай, про кассира реально верю, и более того — не могу припомнить у себя ситуации, когда я после визита к кассиру не задавался бы вопросом — зачем я вообще к нему приходил . И с тем, что учиться по учебникам надо — на 100% согласен. А вот про бухгалтера — точно знаю, что перетереть с ним насчет интеграции или хотя бы импорта проводок придется. Они такие выдумщики бывают на самом деле, эти бухгалтера.
G>Когда разберешься с этими выдумщиками поближе, выясняется, что выдумывают они тогда, когда не знают, как сделать правильно.
Да, ты абсолютно прав. Но от этого не легче. У тебя выбор — объяснять им, как надо делать правильно (для чего надо полюбому разобраться, кстати), или сделать как у них сейчас, чтобы они были довольны. Так как мне платили деньги не за business process reengineering, а за разработку и внедрение специального софта, заточенного под их, пусть кривые, но бизнес-процессы, я выбирал второй вариант. Вопрос в том, за что тебе платят деньги. Если за то, что ты им говоришь "как правильно" — это одно. Если за разработку и внедрение системы — то предполагается, что ты под них подстраиваешься, а не наоборот.
Насчет того, как сделать правильно и бухгалтеров. Главбух вообще-то обязан разработать план счетов для своей компании и схемы проводок первички. Так вот, чем лучше бухгалтер, тем в большую сторону эти вещи будут отличаться от типового плана счетов и типовых проводок. Бухгалтер может вести аналитику по счетам, чтобы получать детальные отчеты, например. Что в типовом плане счетов не прописано. Бухгалтер может оптимизировать схемы проводок. Разумеется, для того всего нужны мозги и понимание бухучета. А типовая схема в учебнике написана, так любой делать может.
Далее. АСУ, с позволения сказать, бухучета, позволяет генерировать проводки автоматически по первичке. "Правильно", по книгам — это далать надо вручную. Коль скоро схемы проводок и планы счетов отличаются от организации к организации, а также оличается и их хозяйственная деятельность — то в общем случае будут отличаться и операции и проводки. В простых случаях — могут измениться счета и субсчета с аналитикой, в более сложных — появятся новые "документы", вообще не имеющие прямого эквивалента в бумажном виде, которые будут генерировать пачки проводок.
По хорошему — надо всегда оперативный учет связывать с бухгалтерским автоматически или полуавтоматически. Вот например, в "золотых страницах" счета-фактуры выписывала бухгалтерия, а не "менеджеры по продажам" — специфика бизнеса такая, на то была причина, изменять это было дорого и сложно — налетели бы на реорганизацию, что сорвало бы нам наш заказ. Имеем — бухгалтерия завязана в процесс продаж, и геморройный был этот процесс, надо сказать. Что сделали — прозрачным образом интегрировали 1Сv7.7 в систему оперативного учета на базе MS SQL + VB (не фокус ни разу — COM рулез форева). Клиент сохранил свой бизнес-процесс, что радикально удешевило внедрение системы, плюс — избавился от геморроя, вызванного этим процессом. Клиент счастлив, считает нас волшебниками. Получилось так именно потому, что мы не учили клиента жить. Мы даем ему то, что он хочет.
G>К сожалению, в ближайшее время не смогу ответить развернуто, на своих примерах. Пиковая нагрузка. Но если ты приведешь конкретный пример, совсем не нужно его подробно описывать, просто укажи суть, я тебе скажу где там ошибка.
Это не интересно, где там ошибка . Кстати, есть популярные схемы, на которых просто нет стандарта, как делать правильно, и поэтому у всех кто во что горазд. Например, продажа и покупка "под реализацию", что не кредит, и не предоплата — товар юридически остается в собственности оптовой компании до момента продажи. А посему, никакими правилами это не регламентируется — это лежит за рамками бухучета, клиент товар на забалансовый счет принимает. Так очень часто работают оптовые торговые компании с розничными магазинами. Менять эту схему, если она крива, они с твих слов не будут. А если начнут — это удлиннит тебе период, через который ты получишь свои деньги, только и всего. То есть пользы от того, что ты им покажешь, где ошибка, для тебя не будет никакой.
G>Пример с приходованием на виртуальный склад не понятен, поскольку ты не указал, зачем они так сделали. Могу предположить, что с компьютером умела работать только одна тетка, и могла оприходовать только на один склад
Здравствуйте, Gaperton, Вы писали: G>Ай-ай. Проватерфолили вы, Алекс, одину ватерфольную проверку, которая вам сильно облегчила бы жизнь. Легковесные прототипы гуя для исполнителей, которые идут между началом разработки и завершением работ по постановке ТЗ. Как раз посерединке.
Согласен. Подумаю что тут можно сделать.
(Порою могут быть проблемы, если этапы 1,2 делает другая организация — "консультанты по реинжинирингу".)
Гап, ты мысли рожаешь просто на лету. Это хорошо, что ты методолог по учебнику, а то бы ты так накуролесил со своей фантазией!
Первое, про русский язык.
Я когда-то кодил годик на низком уровне. Хелпов на русском тогда сосем не было. За тот год я разучился по русски ясно выражаться, всё порывался на хорошем еврейско-английском ответить. Хелпы видишь ли израильтяне писали. Потом пришлось специально восстанавливать русский.
Ты это, аскера не бей, может он суперкодер?
Дальше, в ответ на твои вышеизложенные соображения:
Ты вроде бы и прав, но это по состоянию на 5 лет назад. Не знаю, или я так продвинулся, или ты остался в 2000 году, но сейчас методики такие, что типовые р.м. обследовать почти не нужно. Менеджер продаж, это тоже типовое р.м. Варианто мало. И работа по типовым р.м. заключается не в том, что бы дописать для них их дурдом, а подобрать вариант готового решения или решения на стадии разработки. Ты полгода будешь свое решение отлаживать, а через полгода тебе придется краснеть, когда всё это на свалку и какой-нибудь старпер будет ставить то, в чем он ни уха ни рыла, а ведь король положения.
Это я про типовые р.м., подходы и методики.
Дальше, как я начинаю понимать, наш спор вырос из пустого места, из разницы оценок. Ты обработку обмена 1С и VB считаешь проектной работой, а я считаю это разовой работой, которая выполняется без всякого водопада, на раз. Ты проводки бухгалтера считаешь страшным делом, а считаю, что на 99.9% всё везде одинаково, а где неодинаково я конечно видел, но за этот маразм простите, убивать нужно.
Третье, пока ты не признаешь, что во всех этих ПМ-ах дефект, не позволяющий им накапливать и переиспользовать знания, я тебя уважать не буду
Здравствуйте, A.Lokotkov, Вы писали:
AL>Здравствуйте, Gaperton, Вы писали:
G>>... Истинный вотерфол — это ... математически выверенный дебют, гамбит, и эндшпиль.
AL>Видимо, миттельшпиль, а не гамбит Чего там гамбитить то?
Скорее, да Но можно, наверно, и погамбитить, при желании-то
DM>>Для вотерфольных моделей, и многих итерационных цели две: DM>>1) создать программу DM>>2) написать документацию DM>>Получается вместо одного продукта делается ДВА! _>О боже. Как Вы собираетесь поддерживать проект, не имея документации? Или у SCRUM-мастеров так принято — наследил и убежал, а после меня хоть трава не расти?
Не поверишь, а ведь получается. Достаточно обходиться зарисовками и фотками доски.
А в тех проектах, где была обширная документация — всегда тормоза разработки неслыханные.
За документацию руководство для пользователя не считается
DM>>В гибких методологиях, особенно SCRUM та же ерунда. Только пункт второй вычёркивается и добавляется ещё один DM>>1) создать программу DM>>2) (ВЫЧЕРКНУТЬ) написать документацию DM>>3) создать самоорганизующуюся Команду _>Товарищ, я Вас не вполне понимаю. Вы предлагаете на каждый проект заново команду создавать?
Тебе нужен ответ?
Народ, чеслово, такое ощущение, что я разговариваю с теоретиками из мира разработки.
Кто нить вообще работает? Создаёт ПО? Не проектирует, не анализирует, не брэйнстормит. А просто поговорил и сразу чик-чик по клаве в редакторе — чтобы потом нажать компиляция и вышло ПО, а не груда супер важной документации, которую никто кроме автора не читает :D
DM>А в тех проектах, где была обширная документация — всегда тормоза разработки неслыханные.
Ты софт также быстро разрабатываешь, как отвечаешь на сообщения?
Здравствуйте, VGn, Вы писали:
DM>>А в тех проектах, где была обширная документация — всегда тормоза разработки неслыханные. VGn>Ты софт также быстро разрабатываешь, как отвечаешь на сообщения?
Дык отвечать на сообщения — это ж считай тож самое, что обширную документацию писать. Вот и тормоза неслыханные налицо! Денис молодец, хорошо работает над обоснованиями своих тезисов
. И с тем, что учиться по учебникам надо — на 100% согласен. А вот про бухгалтера — точно знаю, что перетереть с ним насчет интеграции или хотя бы импорта проводок придется. Они такие выдумщики бывают на самом деле, эти бухгалтера. 
