Вождение на заднем сиденье.(история провала одного проекта.)
Запись от XLAT размещена 14.05.2020 в 10:21
Показов 2563
Комментарии 5
|
Вождение на заднем сиденье. (история провала одного проекта.) (из книги Алана Купера "Психбольница в руках пациентов.") Из статьи: (Мишель Куин, журнал San Jose Mercury West от 15 марта1998 года.116), посвященная впечатляющему провалу высокотехнологической начинающей компании General Magic. Автор затрагивает глубинную причину провала продукта, когда упоминает, что Марк Порат (Marc Porat), президент компании, «бросил все силы своей инженерной команды на проектирование устройства их мечты». Мишель Куин пишет без всякой иронии. Кажется совершенно естественным, что проектированием занимается команда инженеров, однако именно это и есть причина проблем. Позже в статье она цитирует одного из инженеров: «Мы так и не поняли, над чем работаем. Спецификация появилась лишь за восемьдвенадцать недель до завершения проекта». И снова ни инженер, ни автор не замечают иронии. По общему тону статьи можно подумать, будто все сложилось бы лучше для General Magic, напиши инженеры черновики спецификации месяцем раньше. Неважно, как рано в процессе разработки появляются спецификации, потому что они неспособны заменить проектирование взаимодействии, И неважно, насколько сильно программисты стараются, потому что они неспособны добиться успеха в проектировании взаимодействия. Кроме того, что их методы, опыт и способности не подходят для этой задачи, они еще и оказываются в центре конфликта интересов пользователя с трудоемкостью программирования. И тем не менее раз за разом компании разрешают разработчикам программного обеспечения управлять процессом разработки, часто от начала и до конца проекта. Иногда этот контроль очевиден, но чаще осуществляется косвенно. Я был свидетелем такого тонкого контроля в одной успешной, среднего размера компании Кремниевой Долины. На собрании присутствовал президент, весьма сведущий деловой человек, основавший компанию, а так же ведущий программист, ответственный за создание продукта президент показал нам продукт и продемонстрировал его мощь, которая была для нас очевидна, как и то, что этой мощью сложно управлять - интерфейс продукта был чрезмерно сложен. Наша команда проектировщиков быстро поняла, что программисты «проектировали» этот продукт по ходу написания кода, - примерно так бобер «проектирует» свою плотину во время ее строительства. Президент пожаловался, что конкурент с более слабым продуктом завоевывает рынок компании, но затруднился объяснить, почему это происходит, поскольку знал, что его собственный продукт мощнее. Президент пригласил нас, рассчитывая на нашу помощь в борьбе с конкурентом, но при этом наделил ведущего разработчика полномочиями делать то, что он сочтет уместным. Нам было ясно, что назрела отчаянная необходимость некоторой переделки поведения продукта, и мы рассказали, как мы себе это представляем. Для нас это была обычная и несложная работа по перепроектированию, в результате которой продукт этой компании за несколько месяцев стал бы гораздо более удобным и практичным, более мощным и приятным - более конкурентоспособным. Ведущий разработчик потряс нас просьбой не вносить изменения во взаимодействия продукта с пользователем. Он считал, что в этой области проблем нет. Ему казалось, что в положении продукта на рынке виноваты недостаточно сведущие в его применении маркетологи компании. Он хотел, чтобы мы подготовили внутренние рекламные материалы, позволяющие маркетологам работать эффективнее. Он полностью отрицал наличие недостатков в продукте, несмотря их на неопровержимые свидетельства - в виде наступающего «более слабого» конкурента. Программисты затрачивают столь много времени и энергии на изучение программного обеспечения, что для инженера казалось непостижимым, как пользователи могут не желать тратить время на изучение плодов его труда. Он с готовностью принимал версию, что источником проблемы является его компания, но полностью отрицал свою роль в создании этой проблемы. Он винил продавцов за то, что они не помогают покупателям изучить продукт. Он был готов работать, чтобы решить проблему, скажем, путем создания новых обучающих материалов, однако совершенно не считал возможными даже намеки на его собственное участие в сложившемся положении продукта. Самодовольство инженера было поразительным. Гордость за создание такого мощного продукта ослепила его, но хуже того, ослепила и президента, который не видел неспособность инженера спроектировать продукт таким образом, чтобы пользователи остались довольны. Продукт данной компании открыл новую нишу на рынке, внедрив новые методы сопровождения систем производства. Компания была быстрорастущей любимицей УоллСтрита и весьма удачно выпустила на рынок свои акции пару лет назад. Ее превозносили в деловой прессе и осыпал и наградами общественные и коммерческие организации. Казалось, компания делает все правильно, и ее рыночная капитализация лишний раз это подчеркивала. Но конкуренты наблюдают за подобным успехом не менее пристально, чем инвесторы, партнеры и сочувствующие. Конкуренты компании отчетливо видели потенциал рынка, и не менее отчетливо - слабость продукта данной компании. Они видели, насколько продукт мощный, насколько он насыщен возможностями, но видели также, что это просто танцующий медведь. Продукт имел передовую функциональность, но не мог осчастливить пользователей. Медведь танцевал, но танцевал плохо. Не нужно быть семи пядей во лбу, чтобы увидеть уязвимое место продукта, поэтому конкуренты просто скопировали многие из функций продукта, но сделали свой продукт более простым в применении. Отчеты, генерируемые этим новым продуктом, были прозрачны для руководителей и отражали динамику, тогда как отчеты в продукте-первопроходце были невразумительны и статичны. Конкурент-выскочка отобрал шестьдесят процентов рынка у первой компании - и это с менее мощным продуктом! Наличие инженерных навыков помешало президенту компании. Упростив создание продукта, этот опыт встал на его пути, мешая увидеть заблуждения ведущего программиста. Глубоко укоренившись в программистской среде, он считал подобное положение вещей совершенно нормальным, тогда как наша команда была в изумлении. Этот президент не имел реальной власти. Его ведущий программист управлял делами компании подобно серому кардиналу. |
Размещено в Об орхитектуре...
Надоела реклама? Зарегистрируйтесь и она исчезнет полностью.
Всего комментариев 5
Комментарии
-
В чем выражалась мощность продукта, если интерфейс/api были говно? Пост про плохой продукт, или про плохого главного программиста?Запись от bedvit размещена 14.05.2020 в 13:39 
-
вы читали по диагонали.
Сообщение от bedvit
...
главный программист - отличный программист.
...
у вас есть любимая программа, которой вы пользуетесь всю свою сознательную жизнь?
я 100% уверен, что в ней есть не меньше десятка функций, которыми вы никогда не пользовались.
и также я уверен, что есть десятки функций о которых вы постоянно мечтаете о их присутствии в этой программе, и вы не понимаете, как вы без них можете до сих пор обходиться.
...
но пост даже не про это, а как раз про наличие НЕОЧЕВИДНЫХ конфликтов в симбиотическом треугольнике
руководители(инвесторы)-инженеры(разработчики)-пользователи(покупатели)
собсно, неочевидность энтих конфликтов вы и доказываете своим вопросом.
раз вы ничего не поняли, я вам советую прочитать всю книгу,
хотя не факт на 100 успех вашего понимания.Запись от XLAT размещена 14.05.2020 в 17:19
-
Книгу, действительно не читал, читал только ваш пост. Собственно, поэтому у вас и спрашиваю. В чем заключается более мощный продукт или менее, в контексте вашей статьи? В чем эта мощность выражается?
Ну скажем так, любимой программы нет, есть рабочая. Часть функционала я не использую, это нормально, остальные десятки функций, о которых мечтал, просто добавил сам в dll.
Что такое "симбиотический треугольник"? Яндекс выдает какую-то дичь "Системная семейная терапия Мюррея Боуэна" и т.д.Запись от bedvit размещена 14.05.2020 в 18:15
-
Сообщение от bedvit
Симбиоз
Симбио́з — форма тесных взаимоотношений между организмами разных видов,
при которой хотя бы один из них получает для себя пользу
треугольник симбиоза это когда его три составляющие не могут существовать друг без друга.
https://interaffairs.ru/i/2019... 646444.jpg
ответы от разных вершин РИП-треугольника могут сильно разнится,
Сообщение от bedvit
этот ответ вам не задумываясь могут дать инвесторы:
Сообщение от bedvit
В КОЛИЧЕСТВЕ ПРОДАННЫХ КОПИЙ ПРОГРАММЫ.
Но сами разрабы измеряли мощь КОЛИЧЕСТВОМ реализованных в программе функций.
Пользователи же определяли мощь по ДОСТУПНОСТИ именно НУЖНЫХ для них функций для их текущих задач.
Лично я думаю ответ инвесторов есть самый правдивый!Запись от XLAT размещена 14.05.2020 в 18:41
-
Вот что я и хотел у вас узнать, еще с первого сообщения.
Теперь фраза:
Верна только в одном из трех вариантов.
Итого, все верно, не вижу противоречий, выпустили продукт с кучей никому не нужных функций. Проектом по факту рулил главный программист,который в этом рынке не разбирался, что для меня несколько странно, обычно
разбирается в текущих реалиях IT рынка.
Итого вернемся к моему первому посту, и дадим ответ: программный продукт с точки зрения потребители и инвесторов слабый, главный программист не компетентен, как руководитель всего проекта.Запись от bedvit размещена 15.05.2020 в 09:46
Сообщение от bedvit
