Тайны мадридского двора. Часть 2.5: ответы на вопросы читателей по предыдущей части

    Цикл публикаций “Тайны мадридского двора” задумывался в намерениях (цитата из первой части):

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

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

    То есть диалога с собственно “коллегами по опасному бизнесу” (в смысле с предпринимателями в сфере производства\внедрения близкого по смыслу софта) не получилось. Видимо, за оных коллег несущественно малым процентом от аудитории Хабра. Mea culpa.

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

    Отвечает Ultima Consulting.

    Greesha:
    … почему оценка заказчика не подпадает под определение «корпоративно-идиотической ереси»? Заказчики по определению более объективны, чем своя команда и босс, «высасывающий чушь из пальца»?

    1. Оценка заказчика, несомненно, во многом субъективна. Однако абсолютной объективностью обладают деньги, которыми он оплачивает наши услуги и, следовательно, зарплату программиста.
      Чем больше доволен заказчик, тем больше он платит денег (чуть упрощая, и при прочих равных). А, вспоминая Мацуситу, “прибыль — мера полезности компании для общества”.
    2. При, опять же, прочих равных — оценка заказчика менее субъективна, нежели оценка босса. Потому что у заказчика есть объективная потребность, нуждающаяся в удовлетворении (задача к решению). У босса — нет.
      Можно сказать, что боссу нужно больше денег, но тогда см. п. 1
      Уместно так же вспомнить Джека Уэлша: “Иерархически устроенная компания повернута лицом к боссу и задом к потребителю”.
    3. При нарушении принципа “при прочих равных” из предыдущего пункта (предположим, ответственный сотрудник заказчика — злобная дрянь и всем из ненависти ставит плохие оценки) сработает автоматический стопор — наши разработчики просто не будут принимать на себя его задачи. Кому охота зазря терять в деньгах?
      Естественным образом возникает проблема, эскалируемая наверх и у заказчика, и нас — которая разрешается административно-кадровым образом.

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


    tangro:
    система вообще не предполагает развития долгосрочных отношений с программистом и заказчиком. Представьте себе типичный огромный энтерпрайз-проект, длящийся годами. На этапе разработки всё будет хорошо, но вот пройдёт пару лет — и большинство задач (процентов 80) будут относиться к поддержке и багфиксингу. И что же вы — будете в каждом случае докапываться кто сделал этот баг много лет назад и списывать расходы на него? Или распределять затраты на всех новых программистов, которые вообще к этому коду раньше отношения не имели, а тут вдруг, оказывается, что они почему-то на ровно месте оштрафованы на %стоимость_фикса% / %количество_разработчиков% денег?

    Автор вопроса меняет местами причину и следствие.

    Система, нами описанная, ориентирована не на поиски виноватых, а на минимизацию поводов для этого: то есть, ошибок. Мало ошибок — мало багфиксинга — мало проблем — мало расходов. Подход, в теории менеджмента известный как “нуль дефектов”.

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

    Правильно — подстраивать систему так, чтобы косяки возникали как можно реже. А для этого необходимо, чтобы они были неприятны. Примерно, как ребенок приучается к горшку. Развернуто здесь.
    “Баг, много лет назад”. Если баг был сделан много лет назад и никому не мешал, скорее всего, это бывшая фича. И под схему обработки ошибок не попадает.

    Касательно системы, “не предполагающей долгосрочных отношений с заказчиком” — бОльшая часть регулярного денежного потока у нас идет от клиентов, с которыми мы работаем более «пары лет».

    Archon:
    Выигрышный алгоритм:

    1. Завышаем сроки исполнения задач. Не сильно, но ощутимо. Как только заказчики начинают привыкать к вашим срокам, дуем ещё немного.
    2. Облизываем заказчиков, объясняя, что ну никак быстрее не получится, родненькие. Общаемся с ними хорошо, чтобы хорошо чувствовалось противопоставление белых и пушистых вас и стандартного айтишника-интроверта, шлющего по любому поводу на три буквы.
    3. Делаем задачи медленно, пишем код как можно проще и прямолинейнее, формально подгоняя его под эти ваши стандарты. На производительность пофигу, трайкэтчим каждый написанный блок, подпираем всё костылями, лишь бы работало.
    4. Какое-то время живём припеваючи, премия за раздутые часы капает, все довольны.
    5. Как только вычеты за ошибки начинают превышать разумный предел и премии перестаёт хватать на красную икру, уходим из компании, сваливая все будущие вычеты поровну на оставшихся неудачников.

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

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

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

    Потаенного смысла в приведенных цитатах искать не стоит — просто так отчего то в голову пришло. Кхм.

    Итак, почему логичная схема Archon не работает, по крайней мере, в наше случае: потому что каждый здоровый человек (то есть — не менее 80% населения) при прочих равных стремится работать хорошо.

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

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

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

    Это с точки зрения теории.

    Практика ее подтверждает (и наша, и миллионов хорошо работающих компаний по всему миру, да и сам факт существования рыночной экономики) — и опровергает человеконенавистническую (nothing personal) схему Archon’а.

    Далее — два вопроса, которые в минимальных вариациях повторяют вопрос Archon’а, и ответ, в общем, тот же:

    Manitou:
    Если заранее известен набор параметров и вес каждого из них, то при такой постановке вопроса, сотрудник будет думать ни о клиенте, а о том как оптимизировать соотношение затраченные усилия\вознаграждение, и выберет из возможного набора KPI те, которые конкретно ему будет проще, в силу каких-то причин, закрыть с минимальными усилиями при максимальной личной выгоде, причем часто будет оказываться, что цели закрываются не совсем с теми результатами, на какие рассчитывает разработчик KPI. Оставшиеся же показатели будут либо выполнены формально, либо вовсе проигнорированы. Так как для сотрудника не будет иметь ровным счетом никакого значения, на сколько выбранный им показатель важен в конечном счете. Всё что мы увидели, получив систему KPI, так это то, что она отлично стимулирует оставаться посредственностями. Ну и смекалку развивает у сотрудников, это тоже стоит отметить.


    dhj:
    Как только я перестаю думать о деньгах — я пишу хороший код.
    Если же программируя я буду думать о бонусах/малусах — то нафиг такое.
    Формальный, автоматический процесс премирования только сподвигнет «сломать систему», писать прямолинейный, не изящный код.

    Это как хрущевки/брежневки — вроде жить можно, но нет в таких домах элегантности.
    Плюс при всякой возможности искать виноватых в коллегах. А как же коллективная ответственность за продукт? Или как в старом монологе — «к пуговицам претензии есть?», а на остальное — все равно?

    Дополнительно для dhj сверх универсального ответа Архону.

    Опять телега впереди лошади.

    Хорошая система тем и хороша, что если вы хорошо исполняете свою работу (пишете хороший код) — вам не нужно думать о деньгах, потому что хорошие деньги за хорошую работу вы получите автоматически.
    И еще раз оговоримся — мы вовсе не считаем собственную схему работу идеальной. Но она, на текущий момент, — лучшая из систем, которую мы своими скромными силами смогли придумать и реализовать. При этом работа по совершенствованию — бесконечна, вне всякого сомнения («кайдзен»).

    Да, по поводу “коллективной ответственности” за продукт. Есть сомнения, что автор вопроса правильно понимает смысл этого термина . “Коллективная ответственность” — это когда за преступление одного еврея сжигают всех евреев. За бегство с поля боя одного бойца расстреливают взвод. За косяк одного программиста штрафуют\увольняют всех. А тимбилдинговое бульканье типа “мы команда и вместе отвечаем за все” — это коллективная безответственность. “Тащи с завода каждый гвоздь, ты здесь хозяин, а не гость”.

    craft_brother
    Сугубо, ИМХО.
    Что измеряете, то и получите.

    Мне всегда представлялось, что ПО — продукт командной работы. А в командной работе важен общий результат, а не то сколько километров пробежал форвард, сколько ног сопернику переломал защитник и сколько раз прыгал за мячом вратарь. Все это не важно, если команда проиграла.
    Вводя индивидуальные KPI вы еще разжигаете конкуренцию и убиваете командную синергию.


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

    Правильным балансом является однозначный приоритет итогового результата. В нашем случае — это прибыль. Автоцитата:

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

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

    Кстати сказать, именно “наоборот” исторически характерно для западной управленческой традиции — в этом кроется причина тамошней популярности в общем то, совершенно очевидных тезисов Голдратта, которыми он переворачивает логику с головы на ноги.

    Касательно же “разжигания конкуренции” индивидуальными КПЭ — ну а что, собственно, плохого в конкуренции между сотрудниками, например, качеством работы? Это же не игра с нулевой суммой, выигрыш одного не означает проигрыша остальных.

    Даже в дремучем СССР пытались такую конкуренцию разворачивать — “соцсоревнования” и “переходящее красное знамя”.

    Joshua
    Мне кажется, есть четыре проблемы:
    1. Есть коллективная ответственность с багами. Должно снижать мотивацию.
    2. Есть личная ответственность с багами. Весь мой опыт говорит мне о том, что продуктивность падает в разы. Это как пройтись по бревну на земле и поднятым на высоту 100 метров. Как только возрастает ответственность за ошибку, то скорость РАДИКАЛЬНО падает. При этом, частота ошибок и стоимость их исправления — не так уж и значительна.
    Т.е. код с учетом исправления багов можно писать значительно дешевле, если не штрафовать разработчиков за баги. А способ понизить стоимость бага = автоматические тесты + кодревью + парное программирование + Разработчики тестирования + те самые тестировщики.
    3. Ни кто не оплатит «Технический долг», т.е. не будет рефакторинга. Формальные правила CodeStyle будут выполняться но код будет ухудшаться.
    4. Если уж идет попытка сделать справедливую стоимость оплаты, в зависимости от пользы компании, то к чему Грейды? Если я младший программист и делаю эту задачу так же хорошо как и старший программист — я должен получать столько же.

    1. “Коллективная ответственность” с багами применяется только в том случае, когда нет возможности установить автора бага. Возможно (и наверняка) такая практика снижает мотивацию — что плохо.

      Однако отсутствие такой ответственности (она у нас не сразу появилась) — влияет на итоговые результаты еще хуже. Благо, нам есть с чем сравнивать.

      Собственно, полная аналогия с коллективной материальной ответственностью на складе — легко себе представить, что будет с сохранностью ТМЦ без такой ответственности. Автору ответа, собственно, и представлять не надо — известно из практики.
    2. А не нужно поднимать бревно на 100 метров. Одного метра, скорее всего, вполне достаточно. И вообще (к вопросу п.1), важна не тяжесть наказания, а его неотвратимость.
      Оптимальное же значение высоты бревна подбирается из анализа статистики и аккуратного (!), желательно в песочнице, экспериментирования.

      А способ понизить стоимость бага = автоматические тесты + кодревью + парное программирование + Разработчики тестирования + те самые тестировщики” — тут, при всем уважении, хочется поерничать. Вы пишете в логике, характерной для внутренних команд разработчиков неспециализированных организаций, сидящих на практически неограниченном бюджете и нелимитированных сроках.

      Иначе сложно понять логику, в которой вы понижаете стоимость бага через кратное (!) увеличение регулярной себестоимости рабочего процесса. Причем, как уже говорилось в первой части (“почему у нас нет тестировщиков”) — затраты эти большей частью зряшные.

      Более того, на длительной перспективе, при отсутствии персональной мотивации разработчика, приводят к обратному эффекту — качество кода монотонно убывает.
    3. В силу того, что время выполнения задачи не ограничено ничем, разумной добросовестности и согласия заказчика его оплачивать, системных препятствий для рефакторинга нет. По крайней мере, мы их не видим. Напротив, лучший код содержит меньше ошибок и, таким образом, увеличивает доход. Это с одной стороны.
      С другой — см. выше ответ Archon’у.
    4. Про справедливую оплату и грейды.
      Знаете, “справедливость” — очень плохое слово, единственно пригодное для оболванивания лузеров (типа “общество\государство социальной справедливости” etc) демагогами всех мастей.
      Именно под лозунгом справедливости совершались самые отвратительные и массовые зверства в человеческой истории (а история нашей страны — ярчайший из примеров).

      Так, например, товарищи из ИГИЛа считают, что было бы в высшей степени справедливым вырезать всех читателей настоящего блога. А Ленин считал, что буржуев справедливее всего вырезать. А Сталин считал, что справедливое состояние мира — когда «последняя Парагвайская социалистическая республика войдет в состав СССР». А Джордж Буш-младший считал, что Саддама справедливо повесить, поскольку он неоднократно пытался устроить покушение на его отца.

      А товарищ Кадыров считает, что русские — бессловесное пьяное быдло, справедливая участь которых — собирать и отправлять деньги на беззаботное процветание истинных воинов. А товарищ Путин в целом согласен с товарищем Кадыровым, плюс железно (!) знает, что работать русские не умеют и не хотят, и единственно чем могут прожить, это раздачей нефтяной халявы добрым царем. Причем то, что 100% этой нефтяной халявы оплачивают страшные геополитические враги, развращенные гейропейцы, это тоже более чем справедливо, и картину мира никак не нарушает.

      В переводе на русский язык “справедливо” означает “как нравится лично мне”. Не более.
      Мы предпочитаем термин «эффективность».

      Грейдовая схема — вполне разумна. Как уже говорилось, за “младших программистов” клиенты платят меньше денег. И не просто так — более компетентный и опытный программист сделает задачу за меньшее количество часов при, как минимум, не меньшем уровне качества.

      Дискутировать же имеет смысл о качестве настроек параметров в грейдовой схеме — про высоту бревна. Но это выходит, как говорится, за рамки.
    Ultima
    38,00
    Компания
    Поделиться публикацией

    Комментарии 18

      0
      А, вспоминая Мацуситу, “прибыль — мера полезности компании для общества”.

      А, понятно. Вы, видимо, не в курсе, что бывают другие критерии.

      www.youtube.com/watch?v=u6XAPnuFjJc
        0
        Знаете, совершенно нет желания вступать в оффтопные дискуссии, но: ворона и письменный стол имеют намного больше общего, нежели измерение востребованности компании\продукта рынком через ее чистую прибыль и проблематика личностной мотивации.
          +1
          Как вы прекрасно подменили полезность для общества востребованностью рынком.
            0
            У меня есть что сказать, помимо того что термины «общество» и «рынок» взаимозаменяемы — именно в контексте тезиса Мацуситы.
            Однако — это тот самый оффтоп, да и просто неинтересно обсуждать азбучные вещи политэкономии, которые со времен как минимум Адама Смита рациональному сомнению не подвергались.
        +3
        Здравствуйте. Извиняюсь за небольшой офтоп, но я заметил, что вас все равно мало комментируют.

        Увидел вашу сегодняшнюю рекламу, с которой вы начали свою экспансию на украинский рынок. И нифига не понял — сплошной пиар и самолюбование. Есть предложение для партнеров 50/50, но тут же написано, что клиент сначала платит всего чвертушку, а остальное как пойдет; при чем клиент имеет право вообще отказаться от системы и получит свои деньги назад (представляю радость ваших партнеров, которые уже потратили эти деньги на зарплаты/аренду/откаты, а тут у них клиенты, которые в условиях кризиса распродают свои активы, еще и все деньги назад требуют).

        Но главное, что я не понял — что за систему вы предлагаете? В рекламе об этом ни слова кроме того, что это подоходит всем и сделает всех счастливыми. Я точно так же могу продавать Excel — в нем можно вести весь учет и делать все отчеты, а у кого не получается, тот просто с руками не из правильного места. Ниже есть ссылка для пользователей, которых вы презрительно назвали эксплуатантами. Но на вашем сайте вообще черт ногу сломит. Оставим в стороне дизайн в духе лабораторной работы студента первого курса. Оставим в стороне даже школьную стилистику ваших маркетологов. Но ведь вы даже материалы не можете как-то логично структурировать. Потратил минут десять, что бы найти описание функционала ваших решений и снова пусто. Даже по ссылке в разделе функционала "далее многобукав для дотошных чтецов" у вас про сам функционал ни слова не написано — только сплошная маркетологичная чушь. Какие методологии планирования складских запасов вы используете; какие CRM-модули реализованы (есть ли хотя бы та же запись звонков для последующей работы с жалобами клиентов, не говоря о классическом ведении клиентов по стадиям), какие возможности доступны через веб-доступ, а какие с помощью мобильных приложений; реализованы ли связки с популярными приложениями для торговых агентов и с популярными платформами интернет-магазинов (в том числе с яндекс-маркетом); как у вас реализована сложная филиальная структура (вы же сами говорите, что мелкий бизнес вас не интересует и вы работаете только с крупными компаниями)??? Список вопросов можно продолжать бесконечно — саповцы и одинэсчики дают ответы. Чего же вы стесняетесь?

        Далее очень важен пункт поддержки. Вы пишите, что у вас поддержка лучше уровня 1С. Уровень 1С всем известен — многоканальный телефон, электронная сапортовская почта, внутренний форум для обладателей сертификатов, своевременные обновления бухгалтерской и налоговой отчетности. У вас на сайте написано, что у вас крутая поддержка то ли таджиков, то ли индусов. Ничего не понятно. В Украине часто практикуют выпускать противоречивые директивы и требовать с наступающего месяца сдавать отчеты по новому, под угрозой штрафов (излюбленный способ наполнения бюджета). В таких случаях 1С: Украина делает официальные письменные запросы, дожидается официального ответа с разъяснениями и в последние дни аврально делает новые отчеты, которые сеть партнеров и фрилансеров быстро распространяет по пользователям. Ваши таджики с индусами тоже будут писать официальные письма-запросы в украинскую налоговую?

        P.S. Все же увольте весь свой отдел маркетинга. Прочитав о вашем сравнении с SAP (до которой вам расти десятилетиями) фразы «бесплатного наследственного хлама», «разлагающегося зомби» и «на тебе, Боже, что нам негоже», а в сравнении с 1С (до которой расти еще больше) — «Глубоко мы с ней, честно скажем, не разбирались», у меня сложилось о вас впечатление как о стартапе, который только вчера родился и кричит на всех углах: дайте нам денег, так как мы лучшие, не знаем в чем, но точно самые лучшие.
          0
          Вот разделяю ваше мнение. Чисто почитать, поржать — прикольно, конечно.
          Но от компании «фонит» студенческой лавкой и тренингами «личностного роста» (в плохом смысле).
          Отдельно вымораживает поливание *** конкурентов.

          Хотя блог компании читаю с удовольствием и нахожу ценные мысли — за это спасибо.
          То, что информация не очень хорошо структурирована (что в статьях, что на сайте) — это, по-моему, не очень критично.
          Если изначально поставить себе задачу «понять автора», то, может быть, даже хорошо — очень сложно сжато и структурировано передать мысль или концепцию. В первой части было много конкретики так что не всё так плохо.
            –2
            Информация на сайте ultimaerp.com структурирована исключительно для потребления целевой аудитории, к которой вы, уже по одной постановке вопросов, никак не относитесь. Равно как и 99,9% аудитории Хабры. Не воспримите ни в коем случае как обиду, это констатация факта.
            Если покупатель журнала Хастлер будет жаловаться на обилие порнографии, а Physical Review — на тотальное отсутствие детских сказок, то это не говорит о некомпетентности редакций этих уважаемых изданий.
            Если же вы ставите вопросы с позиции потенциального партнера на украинском рынке — вот формочка обратной связи www.ultimapartnerscenter.com/become, и там вы сможете получить все ответы.
              0
              Я, как человек обладающий функциями технического директора, пытаюсь расширять свой кругозор и ищу полезные решения, которые могу применить или кому-нибудь посоветовать. Вдруг у вас действительно хороший продукт?
              Информация на сайте ultimaerp.com структурирована исключительно для потребления целевой аудитории, к которой вы, уже по одной постановке вопросов, никак не относитесь.

              Ладно, пусть этот сайт — это шпаргалка для ваших продавцов и источник для презентаций партнеров. А где можно почитать про сами продукты? Что они из себя представляют? Какие бизнес-процессы они покрывают? Что уже предоставляется из коробки? Какие аппаратные требования необходимы? В чем конкретные преимущества перед остальными игроками ERP-рынка? Только что бы там не было херни в духе «мы используем C# и уже только этим одним лучше 1С с их скриптовым языком и саповцев с ихними ABAP и Java» (для справки, Microsoft создали C# как свою собственную проприетарную версию Java).
                0
                www.ultimabusinessware.com — видели этот сайт?
                  +1
                  Да, посмотрел www.ultimabusinessware.com и www.ultimaerp.com Нигде нет конкретики, сплошной маркетинг, лапша на уши и откровенная ложь в отношении конкурентов.

                  К примеру, вы утверждаете, что лучше всех из-за того, что используете базу данных Oracle. А тот же убогий 1С до сих пор сидит на файликах DBF, в которых транзакционные блокировки делают невозможной работу уже пятка пользователей. А теперь смотрим правде в глаза — 1С тоже работает поверх базы данных Oracle. Более того, в московском офисе Oracle уже много лет есть выделенный сотрудник (возможно уже не один), который отвечает за то, что бы Oracle хорошо работал под 1C. И все это при том, что тут же есть мемуары вашего писателя-шутника, в которых он в своей разгильдяйской манере делится воспоминаниями о том, что начинали они в то время, когда появилась 1С: Предприятие 8.1. Хотя насколько мне не изменяет память, то при переходе с 8.0 на 8.1 (или даже раньше) уже помимо MsSQL платформа стала поддерживать PostgreSQL. В процессе развития 8.1 они научились работать из Oracle и с IBM DB. Создатели вашей платформы конечно это все знали, когда начали делать свою собственную систему. Так к чему все эти помои?

                  К слову о помоях. Что тут на хабре, что на всех ваших сайтах вы постоянно между делом полощите конкурентов и свою страну. Прямо сквозит через строки — «обратите на нас внимание, уважаемые западные страны; купите и переселите в свои райские края; ведь мы лучше SAP и Axapta вместе взятых». Как-то у вас отношение к бизнесу совсем не взрослое. Не понимаю, как Юлмарт с вами вообще связался. Делали бесплатно?

                  Но я все же не сдаюсь в поиске информации о вашей системе и возвращаюсь на основной сайт в надежде понять что у вас за продукт. Вижу перечни того, что вы «умеете». С большей частью я знаком и потому сразу иду к теме складской логистики. Вместо описания функциональности какие-то статьи. В первой статье анекдот про Ленина. Во второй статье написано, что у вас есть АДРЕСНОЕ ХРАНЕНИЕ! При этом написано, что те, кто не используют ваше адресное хранение и у них все хорошо — это балаболы. По роду работы я щупал только торговые и кадровые модули САПа и потому буду сравнивать с 1С. В типовых примитивных конфигурациях действительно адресное хранение не фонтан — чисто распечатать отборочные листы кладовщикам. Но еще во времена 8.0 уже было решение от Axelot для автоматизации складских потоков. И мои тогдашние коллеги учавствовали в довольно успешном проекте по автоматизации гигантских ангароподобных складов, где кладовщики ездили по територии на погрузчиках с ТСДшками и всегда точно знали, что в каждом контейнере хранится и на каких дальних стелажаш искать самые мелкие коробочки. И напомню, что это происходило еще до того, как вы решили делать свою систему. Так что все мимо.
                    –4
                    О как.
                    Знаете, это давно известная и исключительно удобная технология разворачивания демагогии — приписать другой стороне заведомую чушь, и ее победительно опровергать.
                    Типа, например, что «убогий 1С до сих пор сидит на файликах DBF, в которых транзакционные блокировки делают невозможной работу уже пятка пользователей».
                    Или «При этом написано, что те, кто не используют ваше адресное хранение и у них все хорошо — это балаболы». И так далее.
                    Ну а классическое «полощите свою страну» и «райские кущи Запада» (сегодня он играет джаз, а завтра Родину продаст) с классическими же для пламенных патриотов грамматическими ошибками в родном языке… Несвежий аромат совкового стиля мЫшления как бы намекает нам на отсутствие перспектив конструктивного диалога. Цивилизационная, она же ценностная пропасть.
                    Соответственно, нет для вас никакого смысла тратить время на изучение наших продуктов. Особенно в технологии «написано про Фому, читаю про Ерему».
                    P.S. Очень напрашивается в конце отсылка к знаменитому анекдоту про песню «Валенки» — но, подозреваю, человек с вашим ником вряд ли оценит юмор. Еще и обидится. Так что просто — спасибо за диалог.
                    И разрешите откланяться.
                0
                >Только что бы там не было херни в духе «мы используем C# и уже только этим одним лучше 1С с их скриптовым языком и саповцев с ихними ABAP и Java» (для справки, Microsoft создали C# как свою собственную проприетарную версию Java).

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

                  Осборн: Я уже читал статьи в прессе о C# [произносится C sharp] и отметил, что многие из них поддерживают предположение (или гипотезу), о том, что C# является клоном или замещением Java от Microsoft. Если вы бы писали заголовки, что бы вы сказали людям об этом языке?

                  Хейлсберг: Во-первых, C# это не клон Java. Во время разработки C# мы смотрели на множество языков. Мы смотрели на C++, смотрели на Java, на Modula 2, C и SmallTalk. Существует много языков, имеющие основные идеи, такие же, как и те, которые использовали мы — например, полная объектная ориентированность, объектная простота и прочее.

                  Источник цитаты

                  На счет преимущества данного языка вы вовсе не убедительны. Я вижу его неоспоримое преимущество только над Axapta с ихним встроенным языком X++ и только за счет открытости, доступности для изучения и большого количества готовых программистов (хотя настоящим специалистам освоить еще один язык при необходимости не сложно). А как Ultima под линухами ворочается? Для интерпретации C# моно использует? Или это исключительно wintel-only система?
            0
            Очень интересный опыт разработки и успешного (!) внедрения KPI для разработчиков. Особенно на фоне того, что что-то не слышно, чтобы крупные компании-разработчики ПО такое практиковали.
            Суммируя, можно выделить следующие ключевые моменты:
            (a) максимальная приближенность программиста к заказчику (получение требований от заказчика, общение с ним, получение feedback)
            (b) отсутствие тестировщиков
            автоматический расчет KPI

            Автор «ожидает получить в каментах конструктивную критику и встречные идеи, не пришедшие в головы нам.» Однако, надо признать, что сделать это не так просто, поскольку не раскрыты проблемы, кот видны изнутри (уверен, что таковые имеются -). Также не освещена работа бизнес-аналитиков. Подозреваю, что они или помогают заказчику формулировать требования, или сами могут выступать в роли заказчика (в теории второе может сломать всю схему — но не факт).

            Несколько мыслей/вопросов на тему.

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

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

            (3) Почему бы не добавить в схему оценку разработчиком заказчика?

            (4) На первый взгляд кажется, что трех градаций объема/сложности задачи недостаточно для равномерной загрузки разработчиков. Можно ввести этап уточнения данного параметра — например, старший разработчик устанавливает примерное кол-во часов, кот может быть потрачено на данную задачу. Или отправляет ее на доработку заказчику, если все так плохо с требованиями.

            (5) Имея оценку трудоемкости задачи мы в теории сможем:

            * сравнивать план с фактом и делать какие-нибудь выводы, например, о разработчике (или оценщике -)
            * предсказывать стоимость задачи и давать эту оценку заказчику

            (6) Текущая схема подразумевает отсутствие специализации у разработчиков, что не очень хорошо. Ведь не все любят и делают всё одинаково. Решить это довольно просто — можно ввести категории задач и привязать их к разработчикам (например, еще и по приоритетам).

            (7) Нет ли проблемы, что надо иметь запас ресурсов-разработчиков для того, чтобы попасть в SLA при пиковых нагрузках? Например, когда 2-3-4 заказчикам надо решить их несколько срочных заявок.

            Напоследок: бывают ли сильно связанные задачи? Интуитивно кажется, что при решении сильно-связанных задач может происходить «взаимная блокировка» разработчиков.
              0
              Антон, благодарю за конструктивный ответ.
              Конечно, проблемы есть. И поэтому система эволюционирует. Однако общая схема и концепция остается неизменной, а основной ее базис — повышение удовлетворенности заказчика, тем более.
              В любом случае возникающие проблемы — это отклонения от стандартного процесса и их приходится решать руками, придумывать для них упреждающие воздействия (собственно что надо поменять в схеме) и после этого ждать следующего отклонения.
              Про аналитиков я планировал сделать аналогичную статью, однако передумал. Но в целом вы угадали задачу аналитика. Базис тот же — чтобы клиент был доволен. Свобода действий аналитика, конечно, значительно больше — он может сам предлагать изменения в процессах, может помогать руководителям отдела сформулировать задачу и так далее. Главное — зарабатывать бабки клиенту. Ну и нам малую толику.

              Теперь к вопросам.
              1. В разных ситуациях по-разному. Если вас интересуют детали, то в группе, занимающейся разработкой платформы документированием занимаются совместно разработчики (собственно тех частей, где документируются детали API) и технический писатель (в основном — поддержка документации пользователя и изменений экранных форм).
              На проектах разработчики не занимаются документированием (если не считать комментирования кода и объектов метаданных). Документированием процессов, как правило, занимаются аналитики или специальные люди со стороны клиента (50/50). Разработчик в обсуждение требований обычно не привлекается, но разработчик у нас сам себе архитектор. Так что разработчик, естесвенно, описывает кратко результат работы, но назвать это документированием нельзя.
              2. Мы небольшая компания, но разработчиков больше 20-30. Однако, схема начала работать когда у нас было 5(пять) разработчиков. Простые командные технологии начали буксовать уже тогда. Уменьшать фонд з/п есть смысл, если доход с сотрудника не превышает расходов от его содержания. Аналогично, и в отношении нас и наших клиентов. Однако, если доход значительно превышает расходы уменьшать его нет смысла — это инвестиции которые приносят деньги. Поясню на примере. За счет внедрения мотивировочной схемы на складе компания смогла увеличить оборот на 40% процентов за год не набирая новых людей. План по набору был примерно на 20-30%. Схему сделали за примерно, пятьсот тысяч рублей (для клиента). 20-30% ФОТ склада — 1.5 миллионов рублей. Неразумная жадность как известно, ведет к потерям.
              3. Потому, что заказчик платит нам деньги, а не разработчик. Если Вы имеете ввиду что попадется неадекватный заказчик, постоянно меняющий требования, то виноват тут будет скорее аналитик, за что и поплатится. В любом случае при проявлениях неадекватного поведения сотрудниками клиента, они лишь тратят деньги собственника компании. Если всех все устраивает — нет проблем, будем жаловаться, но терпеть.
              4. С момента написания статьи мы добавили еще 2. Пока для равномерной загрузки достаточно. В очень редких случаях может потребоваться ручное вмешательство. Плодить сущности с оценкой часов нам не дает бритва Оккама и зравый смысл :)
              5. Да, все верно. Однако, надо понимать, что главная оценка — от заказчика. И если в он хотел попробовать 10 разных шрифтов и 50 оттенков серого для фона формы, то план может сильно отличаться от факта. Однако клиент доволен, значит разработчик молодец.
              6. Специализация есть, но не такая узкопрофильная. По сути — мобильные приложений, веб, и desktop. Необходимость разбираться в чужом незнакомом коде имеет полезные последствия — улучшается читаемость собственного кода и его наполненность комментариями.
              7. Во-первых срочные задачи это аврал. Он не может быть одновременно у нескольких клиентов и продолжительным. Иначе что-то надо менять в консерватории. Так что тут ответ простой — нет, такой проблемы нет.
              8. Бывают, но до сих пор удавалось преодолевать блокировки. Протитипчики, сгенерированные метаданные. Пока удавалось что-то придумать.

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

            Самое читаемое