Так хотел заказчик

1 июля 2014
58

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

Эта фраза – «так хотел заказчик» – универсальное оправдание для всех убогих, кривых и непродуманных и неудобных систем, которые мне доводилось видеть. Айтишники словно испытывают какое-то садистское удовольствие, делая интерфейсы и предлагая сценарии, с которыми нормальному человеку работать невозможно – и еще уверяют, что их клиенты страшно довольны. (Здесь я не разделяю внутренние ИТ и внешних исполнителей – против конечных пользователей они обычно выступают единым фронтом.)

Если человек слаще морковки ничего не видел, он не попросит у вас ананас

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

Дело не в том, что есть какие-то «плохие» айтишники, которые хотят обмануть клиента. Исходная посылка неверна: клиент в принципе не может сформулировать требования к системе.

Простите за банальность, но если бы Стив Джобс ходил и спрашивал заказчиков, каким они видят мобильный телефон, каковы были бы шансы получить в итоге то, что мы сегодня имеем — iPhone и всю индустрию мобильности? Ноль.

Тогда какие есть у нас основания думать, что заказчики видят, какой должна быть ERP, СЭД, CRM? Никаких.

Ответственность за качество решения — целиком на разработчике

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

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

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

Пользователи — не инноваторы. И это нормально

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

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

(Есть еще вариант «сделайте мне, как у наших коллег-конкурентов, только лучше/дешевле» – по большому счету это не инновация, а тиражирование известной практики.)

Традиционный вопрос - «Что делать?»

Однозначно, уходить от привычного сценария «предпроектное обследование — разработка ТЗ – реализация – сдача заказчику». Заказчик не обладает такой силой воображения, чтобы даже по детально прописанным функциональным требованиям представить себе, как будет выглядеть система и согласиться с этим.

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

Facebook даже когда был маленький не спрашивал своих пользователей, что именно они хотят – разработчики делали, как видели сами. Ошибались, исправляли. В итоге — может мы и ворчим на Цукенберга по отдельным поводам, но в целом-то неплохо получилось, ведь так?

 

3860
Поделиться
Коментарии: 58
  • Виктор Федько
    Рейтинг: 337
    Эксперт
    01.07.2014 12:21

    Неплохое название. Действительно, пахнуло английским детективом. сразу вспомнил И. Хмелевскую - "Что сказал покойник?". тоже вполне подходит. ;)

    Эту тему тут уже в разных дискуссия очень часто "разминали". По всем поводам. Можно при желании поднять и посмотреть обсуждения. Не хочется возвращаться к уже пройденному ))).\

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

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

    А вот, ...что заказчики видят, какой должна быть ERP, СЭД, CRM... - основания как раз есть. Нормальный заказчик, зная , что он хочет на выходе, прекрасно понимает как он это что-то может получить с помощью ERP и т.п. , и какими эти системы могут и должны быть. (в данном случае заказчик - это бизнес + переводчик CIO .В одном флаконе).
    Другое дело, что на все случаи жизни, по русски говоря "хотелки" ERP и СЭД не напишешь. От того и пишут стандартные коробки разной степени габаритов. А потом героически дорабатывают под каждого. В меру опыта, понимания, совести и прочего. Это отдельная тема, здесь она тоже упоминалась.

    Пользователи — не инноваторы. - Ой ли? Да не всегда. Иногда именно пользователь , требуя помочь ему с помощью ИТ сделать нечто, как раз подсказывает верный путь. Так что спорно. И это нормально - да не всегда нормально. В общем и целом так и есть, только хорошо ли это? с инноватором -пользователем работать гораздо проще. и результат достигается качественнее и быстрее. Сталкивался с такими. И сейчас работаю.

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

    уходить от привычного сценария «предпроектное обследование — разработка ТЗ – реализация – сдача заказчику».
    Уходить куда ? Я думаю, что цепочку надо подправить. В начало поставить - Желание заказчика по бизнес -требованиям., потом перевод на машинный язык, презентация возможных вариантов., показ решений. Обзор. И потом предпроектное обследование. Заказчик должен стать соучастником процесса через своих полномочных представителей. И нести ответственность за результат вместе с разработчиком. Тогда все и заработает.

    Пример с Цукербергом из той же оперы что и со Стивом Джобсом. Есть просто люди, а есть гении или просто высокоталантливые люди. Их крупицы - и они исключения. Они могут служить идолом, примером для подражания, но не более того. В практической жизни это мало применимо.

    • Станислав Макаров Виктор
      Рейтинг: 17
      Независимый эксперт
      02.07.2014 13:52

      Бизнес -- в лучшем случае -- может в общих чертах сказать, ЧТО он хочет от системы. Но вся кривизна решения обычно проявляется в том КАК это сделано. Вот именно к "КАК" у меня больше всего претензий. Юзабилити корпоративных систем - страх и ужас, без слез не взглянешь. За такой дизайн в потребительском секторе разарабам руки бы поотрывали. И это не про вау-эффект, чтоб везде бантики и бабочки, про обычную productivity.

      И еще: бизнес бизнесу рознь. Очень часто прозрачность, которую несет автоматизация бьет как раз по "бизнесу" - по конкретным людям, с которых мы и собираем требования. А спрашивать на верхнем уровне бесполезно, потому что стейкхолдеры очень редко в курсе, как функционирует весь аппарат.
      Так что бизнес - это скорее испорченный телефон, чем доверенный источник -- даже в части ЧТО хотеть от системы.

      • Виктор Федько Станислав
        Рейтинг: 337
        Эксперт
        02.07.2014 14:29

        бизнес бизнесу рознь.

        Вот тут согласен. Есть разные составляющие.

        Да не должен бизнес в целом предъявлять требования к системе. Бизнес должен сказать, на сколько он хочет прибыль увеличить, себестоимость снизить. Все. Дальше специально обученные люди говорят, с помощью чего это можно сделать и как. Если через КИС - то такую-то и такую-то. Бизнесу нужна конечная цифра в отчете, а не сам отчет и на каком языке он реализован.
        Прозрачность - статья особая. Тут и правда борьба быть может. Но есть иные методы и подходы, как это преодолеть.
        Возможно, я что-то не так понимаю, потому что привык от бизнеса получать четко сформулированную задачу - обеспечить планирование на всех уровнях, обеспечить выдачу информации такой и такой туда и туда. При этом, не в приказном порядке, а в форме совета - нам бы надо так и так, можно ли это сделать. И как это сделать лучше. Такой формат, обычно, дает стопроцентный результат.
        И , кстати, спрашивать на верхнем уровне очень даже бывает полезно. Для меня, в частности. Там есть люди, лучше которых никто не знает как что происходит и крутится. Даже сам технический аппарат не всегда представляет, а топ представляет и дает четкий ответ на любой вопрос. Очень комфортно работать в таких условиях.

        • Станислав Макаров Виктор
          Рейтинг: 17
          Независимый эксперт
          03.07.2014 11:18

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

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

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

          • Виктор Федько Станислав
            Рейтинг: 337
            Эксперт
            03.07.2014 11:25

            Ну, не весь "верхний" бизнес в теме, конечно. CEO более чем в теме, лично курирует все проекты по ИТ, требует расширения, постоянных инноваций в этой сфере. Так же и главный инженер. Этого , в принципе, достаточно. Остальные - по мере сил )))

          • Виктор Федько Станислав
            Рейтинг: 337
            Эксперт
            03.07.2014 11:28

            Не очень понимаю, почему это редкая ситуация сейчас. Лет еще 10-15 назад понимал. Теперь же только и говорят об MBA и прочем. О современных продвинутых менеджерах западного толка, разбирающихся во всем. И похоже , что их становится все больше и больше. Современных управленцев нового типа. Так в чем тогда проблема то?

  • Марк Шварцблат
    Рейтинг: 10
    КТ "Акведук"
    ИТ-директор
    01.07.2014 17:14

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

    Совместное посещение мероприятий так же споспешествует оному.

    • Станислав Макаров Марк
      Рейтинг: 17
      Независимый эксперт
      02.07.2014 13:54

      Да, разумеется -- заказчик должен знать, что потенциально можно сделать на новых технологиях. А там, глядишь, и фантазия разыграется, и аппетит придет.
      Но есть ли примеры, где такое просвещение поставлено на системную основу?

      • Марк Шварцблат Станислав
        Рейтинг: 10
        КТ "Акведук"
        ИТ-директор
        08.07.2014 17:05

        Думаю, что есть. И не только у меня. Но почему-то все молчат. :) Стесняются... :)

      • Виктор Федько Станислав
        Рейтинг: 337
        Эксперт
        08.07.2014 18:56

        Да какая проблема то? Для этого у заказчика , сиречь у бизнеса, существует CIO. Одной из обязанностей которого имхо является регулярное освещение новинок ИТ в области бизнеса топ-менеджмента. По направлениям. С выдачей рекомендаций - почитать то, посетить этот или иной семинар / конференцию. И т.п. Чем и занимаюсь иногда. в свободное от работы время, с переменным успехом. ))

        Возможно, что и на системную основу где-то поставлено. Может, кто расколется из коллег)))

        • Марк Шварцблат Виктор
          Рейтинг: 10
          КТ "Акведук"
          ИТ-директор
          08.07.2014 20:46

          Может потребоваться системное применение терморектального криптоанализатора... :)

  • Владимир Лосев
    Рейтинг: 10
    САНТЭЛ-ТЕЛЕКОМ Москва
    CIO
    02.07.2014 10:37

    Полностью согласен с автором.Здесь даже нет предмета для дискуссии.Давно придуман термин WEB 2.0. Его идея проста как апельсин - Пользователь должен сам определять и формировать свое информационное окружение. Точка!
    Смешно когда наши "эксперты", наморщив лобики с умным видом пытаются дать "свое виденье" термина, давно ставшего классическим.
    Именно об этом, например, говорит Э. Кодд, сформулировавший 12 требований к OLAP-системам. Некоторые "специалисты" пытались их "дополнять и расширять". Но это уже классика, которая самодостаточна, а из "дополнительных требований" торчат уши их убогих решений на "лучших практиках".
    Грустно это наблюдать ...
    Дайте Конечному Пользователю решать свои задачи, а не биться со сложностями инструмента. Не его это дело!.
    По этому поводу неплохо вспомнить один из основных постулатов эргономики:
    "Произведение сложности решаемой задачи на сложность инструмента равна CONST".
    В том "букваре" по эргономике, который мне попался на глаза много-много лет назад, была приведена действительная история, прекрасно и поразительно ярко иллюстрирующая этот постулат:
    В средневековой Европе, до прихода туда "арабской" (позиционной системы счисления), пользовались "римской" нотацией. Если кто-то попытается ее использовать для вычислений, то поймет, почему учились работе с "римскими" цифрами годами. Были даже доктора наук по умножению, делению и т.д. И вдруг пришла "арабская", позиционная система счисления. Любой "школяр" "в столбик" за минуты стал решать задачи, которые требовали годов упорного обучения, докторских степеней и т.д.Наверное, ни у кого нет вопроса, как отнеслись эти уважаемые, заслуженные профессора и доктора к этим новым технологиям ... Вся их наука (да и жизнь) оказалась спущенной в отхожее место.
    Разработчики должны научиться делать инструменты с интерфейсом естественным как воздух, которым мы дышим и не думаем, когда и как сделать вдох или выдох, по каким каналам воздух идет, какие сложнейшие преобразования стоят за этим "действием на автомате" - вдох и выдох.
    И для справки.
    (Возможно, что кто-то пропустил эту случайно прорвавшуюся в прессу новость.)
    Агентство DARPA уже придумало новый термин "семантический компьютинг" и вливает в эти разработки немереные ярды зелени.
    За термином "семантический компьютинг" стоит очень простая мысль: Пользователю следует автоматически предоставлять его "семантический слой" (User Semantic Layer), причем, на его родном языке, в терминах его предметной области и в строгом соответствии с его правами на доступ к данным. При этом Пользователю будет дан инструмент, с которым он без посредников должен общаться с автоматом и самостоятельно формировать нужное ему "здесь и сейчас" информационное окружение (по сути - WEB 2.0)
    Самое смешное в этой истории то, что прототип системы с близкими к этим требованиям характеристиками создан и "обкатан" нами (на многих типах ИС с разными СУБД) много лет назад. Уже даже прототип "облачного"варианта (SaaS BI-OLAP-Reporting) оказался среди победителей двух серьезных "облачных" конкурсов, проведенных Microsoft & IAMCP и Vimpelcom & CNEWS, но ... Н-и-з-з-з-з-я !
    Чем же тогда будут заниматься "доктора наук по сложению и умножению".
    О последствиях даже говорить страшно ...
    Это действительно уже детектив.
    Фактически погибнет вся «поддержка» внедренных (или внедряемых) ИС, т.е. основной «бизнес» подавляющего большинства компаний, зарабатывающих от $80 до $500+ в час на этой «поддержке». (Цифры от для «1С» и до SAP.)
    Но это все равно неизбежно. Если не мы, то DARPA или кто-то еще.
    А мы опять будем внедрять "лучшие практики" ...

  • Александр Огнивцев
    Рейтинг: 60
    Атомстройэкспорт
    Зам директора по ИТ
    02.07.2014 10:51

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

    • Станислав Макаров Александр
      Рейтинг: 17
      Независимый эксперт
      02.07.2014 14:01

      Теоретически да -- аналитики должны предлагать решение, понимая что ключевым выгодоприобретателем будет владелец бизнеса, но при этом система не вызовет отторжение и саботаж на всех прочих уровнях, от топ-менеджмента до рядового исполнителя.
      "Но, Холмс, чёрт возьми - как?"

      • Александр Огнивцев Станислав
        Рейтинг: 60
        Атомстройэкспорт
        Зам директора по ИТ
        02.07.2014 15:53

        Ну уж нет!!! Это был мой вопрос - как! :)

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

  • Ольга Мельник
    Рейтинг: 200
    Независимый эксперт
    02.07.2014 11:52

    Про семантический компьютинг очень интересно. Думаю, такой подход потребует качественного скачка приложений, но неизбежен: здорово же! Только времени потребуется порядком. Как и с облаками: нужно время, чтобы нарастить инструментарий.
    А что касается нынешней ситуации, врезалась в память такая история. Производство, легкая промышленность. Задача автоматизации и оптимизации раскроя тканей. Есть бизнес-пользователь: начальник линии раскроя, пожилая энергичная дама. Есть подрядчики: молодые ребята, активно двигающие на российский рынок некую буржуйскую систему для этого самого раскроя. Есть ИТ-директор, которому вся возня с раскроем ну совершенно пофигу, одна головная боль. Разработчики много месяцев пишут нечто для того, чтобы подогнать свою систему под задачи клиента, читай - начальника раскроя. 60 тыс. строк кода. Реализовали массу своих идей, придумали, как будет лучше. Причем делают они все за свой счет: заказчик первый, ключевой, если все получится - рынок почти наверняка их, стоит рискнуть. Совещание по поводу принятия работы. Ребята докладывают, что сделали. Все тихо слушают, пока не встает ИТ директор и не задает несколько вопросов. Ой, говорит тут начальник раскроя, а ведь и правда! Я не того хотела, что ребята сделали, мне то нужно, что Ит директор сказал....60 тыс строк и месяцы работы - псу под хвост. Не могут разработчики сами решения предлагать...

    • Виктор Федько Ольга
      Рейтинг: 337
      Эксперт
      02.07.2014 13:00

      чтобы подогнать свою систему под задачи клиента,

      Тут интересный момент - а задачи они сняли с клиента и просто решили, что так будет лучше ? Это существенно.

      И еще. Если они сделали нормальную систему, а заказчик начинает хмурить брови, то идеальным был бы такой исход ;
      После слов Я не того хотела, что ребята сделали, мне то нужно, что Ит директор сказал.. должен был вступить CEO со следующим текстом :

      " Отлично, дорогой начальник раскроя и ИТ-директор ! Вы молодцы !. Но где вы были раньше ? А посему - оплата разработки из вашего кармана. Можете заказывать следующую - тоже из вашего! "
      Я Вас уверяю, и вопросы бы снялись, и система бы оказалась замечательной! и все бы мгновенно заработало.

    • Марк Шварцблат Ольга
      Рейтинг: 10
      КТ "Акведук"
      ИТ-директор
      05.07.2014 21:23

      Все по спирали... Электронные таблицы сделают ненужным программистов, dBase- подобные системы сделают ненужными программистов, визуальные среды сделают ненужными программистов... ;)

      • Виктор Федько Марк
        Рейтинг: 337
        Эксперт
        05.07.2014 22:37

        Ну да. "А вот давайте поговорим с вами лет через 20. Ничего вокруг не будет.Одно сплошное телевидение"(с) ))))

        • Марк Шварцблат Виктор
          Рейтинг: 10
          КТ "Акведук"
          ИТ-директор
          06.07.2014 22:09

          Вроде бы если ©, то «Наступит время, и телевидение перевернет жизнь человечества. Не будет ни книг, ни кино, ни театра, будет одно сплошное телевидение».

      • Ольга Мельник Марк
        Рейтинг: 200
        Независимый эксперт
        06.07.2014 14:52

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

        • Виктор Федько Ольга
          Рейтинг: 337
          Эксперт
          06.07.2014 19:39

          только наслаждаться совершенством ? Вашими бы устами. Да и вообще, не интересно это - только наслаждаться)))). Нельзя жить так хорошо. Нужно портить себе удовольствие)))

          • Ольга Мельник Виктор
            Рейтинг: 200
            Независимый эксперт
            06.07.2014 19:55

            Я позволю себе кулинарную аналогию. Вот готовим мы с Вами что-то вкусное, а у нас то миксер сгорел, то комбайн не рубит ничего, то нож опять затупился, то просто ну нет правильного инструмента в магазине, и вы идете его быстренько тачать сам с помощью лобзика и зубила. И мы с вами все время заняты процессом подготовки инструментов, а не собственно готовкой. Или вы мне говорите - ну и что, что неудобно держать! А ты вот за спину руку загни, и там и режь вслепую, да! Нет, по другому не работает, режь так.
            А тут - о счастье! - ну после семантического комьютинга - у нас все работает постоянно. Есть ВСЕ инструменты, а если нет, мы их быстро подкачиваем из сети. И мы готовим, о качестве соуса думаем, а не то том, как бы миксер починить.... Разве плохо будет? Хочу такое время застать.

            • Виктор Федько Ольга
              Рейтинг: 337
              Эксперт
              06.07.2014 20:13

              Больше всего люблю именно кулинарные аналогии ))).

              Да, все верно - но это идеальное состояние. Нечто совершенное и почти недостижимое. Застать тоже хочу. И все это когда-то будет, наверное. Вот только жить в эту пору прекрасную))))

        • Марк Шварцблат Ольга
          Рейтинг: 10
          КТ "Акведук"
          ИТ-директор
          06.07.2014 22:29

          Т.н. "семантическое программирование" - это очередная попытка избавиться от прикладных программистов. И также закончится ничем. :) Что-то подобное уже даже было в начале 90-х - была даже какая-то среда, с которой пришлось разбираться, которая в свою очередь позволяла писать" типа программы" на обычном английском языке. Мы ее хотели приспособить для написания тестов. И в каком-то курсе теорию программирования на "естественных языках" частично доносили. Т.е. это уже тоже было. Для подобного надо, чтобы со стороны компьютера был искусственный интеллект, близкий по возможностям к человеческому.

          Совершенство недостижимо... :)

          • Ольга Мельник Марк
            Рейтинг: 200
            Независимый эксперт
            06.07.2014 23:24

            Все разделяю, кроме тезиса "совершенно недостижимо". Вся научная фантастика показывает: надо только мечтать посильней, и можно проходить сквозь стены (ну еще верить в себя надо, вы знаете....). Если это удобно и все хотят - это будет. И даже теоретически это достижимо, другое дело что сложно и долго. Системы распознавания речи, печатного и рукописного текста, образов вообще тоже не быстро развиваются, но постепенно выходят на промышленный уровень. Так и здесь будет. Но нескоро. От "Наутилуса" до первых подлодок - 50 лет, время есть, долгие нам с вами лета...

            • Виктор Федько Ольга
              Рейтинг: 337
              Эксперт
              07.07.2014 08:00

              На мой взгляд, речь идет о следующем витке появления языков программирования высокого уровня. Марк вот , мне кажется, это затронул в предыдущем посте. Было уже это. Я помню, как году в 1985-1987, когда появились первые средства телекоммуникационного доступа, базы данных типа Adabas - тут же появились высокоуровневые языки типа Adascript+ , Natural. Прорыв в то время. Простые и понятные для писания запросов к БД (по сравнению с PL1, конечно :) ). И многие пользователи стали на них обучаться, и многих получалось на самом деле. Небольшие запросы, выборки. И программист не нужен :))). Потом все затухло, конечно. Революция продолжалась. Но без программистов - никуда.
              Хотя бы потому, что - а кто будет создавать простые языки для пользователя? :) Системы распознавания текстов? И т.д.

              Хотя...

              Жить и верить - это замечательно.
              Перед нами - небывалые пути:
              Утверждают космонавты и мечтатели,
              Что на Марсе будут яблони цвести.

            • Марк Шварцблат Ольга
              Рейтинг: 10
              КТ "Акведук"
              ИТ-директор
              07.07.2014 09:19

              А вот не надо путать прогресс как таковой и идеальный (совершенный ) объект, как продукт фантазирования. :)

  • Ольга Мельник
    Рейтинг: 200
    Независимый эксперт
    02.07.2014 13:18

    Насколько я поняла, разработчики САМИ решили, КАК будет лучше...они что-то предлагали, раскрой на что-то соглашался, и вроде всем все было понятно, пока не выплыл слой, поднятый ИТ директором. А за эти 60 тыс строк так и не заплатили ничего разработчикам. Мне почему-то в этот раз было жалко именно их. Ребята старались, писали чего-то...и вот. Неверно построен был процесс с самого начала.

    • Станислав Макаров Ольга
      Рейтинг: 17
      Независимый эксперт
      02.07.2014 14:04

      внутренние коммуникации - слабое звено многих проектов. мало придумать клевую вещь, надо разъяснять и разъяснять, до полного понимания всеми сторонами. нельзя было ИТ-директора игнорить.

      • Виктор Федько Станислав
        Рейтинг: 337
        Эксперт
        02.07.2014 14:47

        А там не ИТ-директор. Там завхоз скорее всего. Нормальный CIO не позволяет себя игнорировать ни при каких условиях. На его поле можно играть только по его правилам. И если он такое допускает - так и что тут удивительного?

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

    • Виктор Федько Ольга
      Рейтинг: 337
      Эксперт
      02.07.2014 14:11

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

      • Владимир Лосев Виктор
        Рейтинг: 10
        САНТЭЛ-ТЕЛЕКОМ Москва
        CIO
        02.07.2014 14:38

        Для японского менталитета это вообще не вопрос. Их принцип - разработчик должен знать что требуется заказчику лучше заказчика.

    • Виктор Федько Ольга
      Рейтинг: 337
      Эксперт
      06.07.2014 20:00

      разработчики САМИ решили, КАК будет лучше.

      Вот какой еще вопрос возник по ходу. А ребята эти - они хорошо разбираются в технологии данного производства? От и до? Работали в этой сфере? Учет и автоматизация раскроя - это не такое простое дело. Там много подводных камней. Особенно при бух. учете. Да и при всем остальном тоже. Знаю, о чем говорю - Проходил это года полтора-два назад , правда на раскрое металла. Та еще тема ))). И это при полной поддержки всех заинтересованных служб. Каждый старался как мог. Решение нашли, конечно, сейчас все работает. Но не так все просто.
      А там - сами по себе, Да еще слой ,ИТ-директором поднятый, выплыл. Интересно, какой слой - в части ИТ или технологии ? Он там специалист в производстве серьезный?
      В любом случае - задача была обречена изначально, похоже.

      • Ольга Мельник Виктор
        Рейтинг: 200
        Независимый эксперт
        06.07.2014 20:25

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

        • Виктор Федько Ольга
          Рейтинг: 337
          Эксперт
          06.07.2014 20:38

          Вот и я о том же. Значит - чистая политика. Только зачем было так ребят подставлять ? Как-то неприлично. Тем более, на деньги.

  • 02.07.2014 13:51

    "Пользователь не знает, чего он хочет, пока не увидит то, что он получил"

    • Виктор Федько
      Рейтинг: 337
      Эксперт
      02.07.2014 14:08

      Вот точно! Сталкивался с таким. Вы делайте, покажите, что получилось, а мы оценим и скажем - то или нет. Я эту "игру в одни ворота" у себя быстро прекратил. Пиши, что хочешь и подписывай. Делаем, смотрим, тестируем, запускаем. Не подходит - поговорим отдельно ;)

      • Станислав Макаров Виктор
        Рейтинг: 17
        Независимый эксперт
        03.07.2014 00:11

        Но разве пользователь пишет функциональные требования и требования к юзабилити? В лучшем случае - бизнес требования. Типа "Я хочу, чтобы время реагирования на предписания по контролю качества сократилось на 10%" или "чтобы удовлетворенность клиентов возросла на 14%". Или не так?

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

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

        • Виктор Федько Станислав
          Рейтинг: 337
          Эксперт
          03.07.2014 08:16

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

          Про удовлетворенность клиента на 14 % и т.п. - это из серии - а сколько звезд на небе ? ХХХХХХХХХХХХХХХХХХХХХ. Точно? А вы проверьте.

          И бизнес тоже разный .Нам повезло с тем, что сейчас ряд руководителей производства среднего звена научились с нашей помощью четко формулировать требования. Описывать, что хотят видеть и в каком виде. Это очень помогает.
          Некоторые начальники напрямую работают с внешним подрядчиком (есть у меня один такой внешник), формулируют ему задачу, уточняют. Потом принимают работу. Я только согласовываю сроки и деньги., а также нюансы, если может возникнуть конфликт интересов с другой системой. Но в любом случае все тут же документируется, подписывается, а потом реализовывается. И никаких "я вовсе не это имел в виду".
          "Подсунуть" не получается. Да и глупо это. Отвечать все равно буду я . Права даны большие, Но и спрос соответствующий.
          Поэтому и необходимо движение навстречу друг другу - ИТ должно разбираться в предметной области, бизнес - в ИТ. на определенных уровнях. Это аксиома.

          Вот здесь уже все на эту тему было сказано. Если не все, то многое.

    • Станислав Макаров
      Рейтинг: 17
      Независимый эксперт
      02.07.2014 14:30

      таки это agile - быстро делать макет, получать фидбэк и двигаться дальше.

      • Виктор Федько Станислав
        Рейтинг: 337
        Эксперт
        02.07.2014 14:36

        А это смотря какой фидбэк. после иного - двигаться хочется и вовсе вон на улицу. Agile, все-таки, предполагает взаимную ответственность и СОучастие.

  • Эдуард Иванов
    Рейтинг: 13
    74.ru
    Руководитель ИТ
    02.07.2014 13:52

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

    • Станислав Макаров Эдуард
      Рейтинг: 17
      Независимый эксперт
      02.07.2014 14:33

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

      • Виктор Федько Станислав
        Рейтинг: 337
        Эксперт
        02.07.2014 14:41

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

        • Станислав Макаров Виктор
          Рейтинг: 17
          Независимый эксперт
          03.07.2014 00:12

          Это точно! Но как распознать жулика?

          • Виктор Федько Станислав
            Рейтинг: 337
            Эксперт
            03.07.2014 08:20

            Да есть много способов. Основной, имхо - это личный опыт. А также набор специальных предварительных вопросов, при выборе поставщика. И шаблоны ответов. Если не впишутся - жулики или не понимают. о чем идет речь.
            Надо смотреть резюме конкретных специалистов Исполнителя - где работали, что делали. Они же не на Марсе делали. Все можно проверить.
            Тут уж у каждого свои подходы.

    • Виктор Федько Эдуард
      Рейтинг: 337
      Эксперт
      02.07.2014 14:38

      Вот тут на эту тему много говорено. ))). Посмотрите. Да и не только тут. Много раз уже эти вопросы поднимались в разных дискуссиях.

    • Владимир Лосев Эдуард
      Рейтинг: 10
      САНТЭЛ-ТЕЛЕКОМ Москва
      CIO
      02.07.2014 15:18

      Голодный исполнитель никогда не будет перфекционистом. Впрочем, как и сытый.Кто-нибудь задумывался о том, почему цивилизация возникла в средиземноморье?Севернее – понятно, почему не у них. Там чтобы выжить, нужно было работать с утра до ночи круглый год., думать об одежде и заготовке дров и т.д.. Отвлекаться на "философические" размышления и ваяние Венер и Аполлонов на севере времени не было.Южнее - другая крайность - фиговый листок сорвал и уже одет, палку воткнул и она растет, а когда голоден - сорви банан или еще что-нибудь в пределах вытянутой руки. Им и без философии, скульптур и прочего было и так хорошо.А средиземноморье делало необходимой работу и, в то же время, оставляло достаточно возможностей украшать свою жизнь скульптурами, заниматься созерцанием, развитием, философией ...Поэтому, когда выбираете исполнителей, посмотрите на них со всех точек зрения.

  • Дмитрий Бацюро
    Рейтинг: 10
    -
    независимый эксперт по управлению ИТ
    04.07.2014 11:02

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

    Это две крайних точки на континуальной оси позиций, которые ИТ может занимать в организации. А нахождение системы в крайнем положении из всего возможного диапазона состояний, как правило, не является оптимальной позицией. Надо искать золотую середину, исходя из уровня понимания текущих и умения предвосхищать завтрашние потребности бизнеса, а также уровня зрелости самого бизнеса. При этом - прилагать усилия для повышения этого самого уровня зрелости бизнеса в части развития своих процессов и технологий, обеспечивая не "технологическую гордыню", а "технологическое лидерство" - сбалансированный хайтек в области руководства IT ("руководства" - в смысле термина "IT Governance"). Именно это - т.е. определение текущей оптимальной позиции ИТ на этой оси в данный конкретный момент и повышение уровня зрелости компании в этой области - и есть одна из основных задач CIO, а вовсе не настройка Циски и не iPadизация всея топ-менеджмента, чем некоторые занимаются.

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

    • Виктор Федько Дмитрий
      Рейтинг: 337
      Эксперт
      04.07.2014 11:37

      А золотая середина определяется тремя факторами имхо :

      1. Степень важности и критичности ИТ для бизнеса
      2. Понимание этой степени бизнесом
      3. Самопозиционирование ИТ (читай - CIO как личности) в данном бизнесе.

      • Дмитрий Бацюро Виктор
        Рейтинг: 10
        -
        независимый эксперт по управлению ИТ
        04.07.2014 17:22

        Это как раз перекладывается на те параметры функции, о которой я написал в предыдущем посте: степень важности/критичности ИТ для бизнеса и понимание этого бизнесом четко коррелирует с конкретной компанией и историческим моментом в ней, ну а ваш п. 3 - это про личность CIO.

  • Дмитрий Кудрявцев
    Рейтинг: 10
    CIO-on-demand.ru
    партнёр
    10.07.2014 11:23

    У меня вся ИТ-карьера, фактически, сервисная. То есть, я появлялся на поле боя уже после автоматизаторов и собирал камни, трупы и раненых. И тут такая тема получается: вот это вот деление на "проектантов" и "саппортёров", которое так любят доставать консультанты-автоматизаторы из кармана, и есть основа проблемы. Ракурсы у них разные, а в результате - породы. Первым действительно после проекта хоть трава не расти, им дальше бежать. А вторым - жить с этим, а в худшем случае - "перебирать движок".

    С инновациями всегда так: одному "загорелось", удалось выскочить из инерции ситуации и создать "свою" версию этой ситуации, а меняется-то она по своим законам и всегда - существенно после того -- первого -- скачка. Ну обычный квантовый переход, для которого копится потенциал. И тут выплывает весьма очевидный момент.

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

    А отдача у нас в чём? От "роботов" ждут только одного - сжатия времени на обработку информации, которая у нас используется практически лишь в двух процессах: подготовка принятия решений и фиксация сопутствующих этому решению фактов. Я специально опускаю замену рабочих рук роботами, это промышленная автоматизация и совсем другая история.

    Теперь возьмите любую бизнес-модель, посмотрите, где тут и кто и на основании какой информации принимает решение. А как часто? А среда вокруг этого ЛПР подгоняет ускоряться? Нет? Ура, есть заказчик, ему можно что-то наавтоматизировать. Но чем это заканчивается, напрямую зависит от дыма из одного места заказчика, того самого ЛПР. Где у него медленно собирается пять циферок под решение, куда рулить - там и дымится. Вот это всё "дорого производите - давайте автоматизируем и снизим ТСО" - вообще до лампочки, если нет давления конкурентов, рынок растёт. Только скорость подачи информации в дашборд интересна, да своевременность и аккуратность отчётности, чтобы почём зря не кошмарили.

    Про дашборды история, вообще-то весьма грустная: это сейчас много продаётся под запуск "рестайлинг"-версий доселе "аналоговых" бизнес-моделей: ну там, с онлайн-инструментами взаимодействия с клиентами и аналитикой, всякими just-in-time цепочками поставок и т.п., но продают-то кому? Тем, кто сидит в плотном конкурентном рынке, где любой процент эффективности бизнеса = скорости реагирования на заказы. Это уже "таблетка от агонии".

    Так что, если не играться в удовлетворение своего эго, то другого подхода тут мне и не видится, если честно.

Предметная область
Отрасль
Управление