D>>>Сам страдаю оптимизмом при планировании. Что посоветуете прочитать по метрикам? (Я не уверен, что их использование может сильно повысить точность прогнозов планирования. Считаю, что только анализ статистики по выполненным и невыполненным работам, может способствовать этому)

VGn>> Мыши плакали, кололись, но продолжали жрать кактус.

_D>К сожалению, не понял к чему это. Поясните.

Шутка на тему непоколебимости.
Обычно, если у меня проблемы, я начинаю искать, что я делаю не так.
А здесь очень близко: "страдаю" и "считаю".
Может стоит попробовать что-то изменить?
То что Вам нужно называется "оценка рисков".
В первом приближении всё просто — помножаете вероятность риска на ущерб и добавляете к общим затратам времени (Вигерс).

Здравствуйте, VGn, Вы писали:

D>>>>Сам страдаю оптимизмом при планировании. Что посоветуете прочитать по метрикам? (Я не уверен, что их использование может сильно повысить точность прогнозов планирования. Считаю, что только анализ статистики по выполненным и невыполненным работам, может способствовать этому)

VGn>>> Мыши плакали, кололись, но продолжали жрать кактус.

_D>>К сожалению, не понял к чему это. Поясните.

VGn>Шутка на тему непоколебимости.
С этим, вроде, всё в порядке
VGn>Обычно, если у меня проблемы, я начинаю искать, что я делаю не так.
Согласен. Аналогично.
VGn>А здесь очень близко: "страдаю" и "считаю".
"считаю" определяется исходя из имеющейся информации.
"страдаю" — скорее всего, от нехватки оной.
VGn>Может стоит попробовать что-то изменить?
Конечно. Любой прогресс — это изменения.
VGn>То что Вам нужно называется "оценка рисков".
VGn>В первом приближении всё просто — помножаете вероятность риска на ущерб и добавляете к общим затратам времени (Вигерс).
Спасибо за информацию. Прочту, в ближайшее время.

VGn>Очень интересно. И какая же дистанция должна быть между ПМ-ом и разработчиком?
VGn>Можно скатиться до полного формализма — тогда все утонут в бумаге.
VGn>Можно ввести обязательное коленопреклонение — тогда ПМ никогда не услышит критики или совета от разработчика. Если вы ненавидите критику и не уважаете подчинённых — тогда это ваш путь. Только это — малоэффективно и обижает гордых и независимых.
Почему Вы, да и не только Вы считаете, что держать дистанцию, это обязательно ничего не слышать и не принимать участие в работе команды? Держать дистанцию, это оставаться в чисто рабочих отношениях с персоналом.
У нас люди считают как? Если начальник добрый, то давайте ему садится на шею. Если после этого он начинает возмущаться — начинаем говорить, что он гад полный и не радеет за коллектив, да и вообще жлоб.
В общем и целом держать дистанцию должны не только и не столько руководители, а в первую очередь продчиненные (я именно про подчиненных говорил) и не превращать добрые отношения в коллективе в панибратство.

Здравствуйте, Nikolay_Ch, Вы писали:

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

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

N_C>В общем и целом держать дистанцию должны не только и не столько руководители, а в первую очередь продчиненные (я именно про подчиненных говорил) и не превращать добрые отношения в коллективе в панибратство.

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

G>Откуда это вы знаете, что люди у нас считают именно так? Мне кажется, вы личные свои проблемы и мысли проецируете на людей, которые, как вам кажется, считают. Надо всего-то уметь — не смешивать личное и работу. И все.
Ну-ну... Сдается мне, что Вы просто мало работали с людьми (я имею ввиду, количественно, а не качественно). Хорошо, пусть будет так как Вы считаете, хотя я гораздо чаще встречал ситуации говорящие об обратном.

N_C>>В общем и целом держать дистанцию должны не только и не столько руководители, а в первую очередь продчиненные (я именно про подчиненных говорил) и не превращать добрые отношения в коллективе в панибратство.
G>Только от руководителя зависит, смешивает он личное и работу, или нет. Только. Если он умеет эти вещи разделять — то все будет в порядке, и не надо будет никаких "дистанций" держать никому. Если нет — то никакие "дистанции" не помогут.
Не согласен. Руководитель может хоть обнапрячься, но если подчиненные считают иначе — они не будут его понимать. Опять-же Вы считаете со своей колокольни, а там у Вас разговор простой — не устраивает — уволить.

Здравствуйте, Nikolay_Ch, Вы писали:

G>>Откуда это вы знаете, что люди у нас считают именно так? Мне кажется, вы личные свои проблемы и мысли проецируете на людей, которые, как вам кажется, считают. Надо всего-то уметь — не смешивать личное и работу. И все.
N_C>Ну-ну... Сдается мне, что Вы просто мало работали с людьми (я имею ввиду, количественно, а не качественно). Хорошо, пусть будет так как Вы считаете, хотя я гораздо чаще встречал ситуации говорящие об обратном.

Ой, смотрите-ка:

Не — держите меня трое, меня умиляет человек, который меньше года управляет персоналом, а теперь учит как "собакам"-"разрабам" (оба теримна от Nikolay_Ch) гайки закручивать и подписывается под лозунгом "атутисты-программисты".

Да это же про Вас — в соседней ветке! Я бы на Вашем месте про опыт работы с людьми, гхм, промолчал, Николай.

N_C>>>В общем и целом держать дистанцию должны не только и не столько руководители, а в первую очередь продчиненные (я именно про подчиненных говорил) и не превращать добрые отношения в коллективе в панибратство.
G>>Только от руководителя зависит, смешивает он личное и работу, или нет. Только. Если он умеет эти вещи разделять — то все будет в порядке, и не надо будет никаких "дистанций" держать никому. Если нет — то никакие "дистанции" не помогут.
N_C>Не согласен. Руководитель может хоть обнапрячься, но если подчиненные считают иначе — они не будут его понимать. Опять-же Вы считаете со своей колокольни, а там у Вас разговор простой — не устраивает — уволить.

Врать, выдумавать и клеветать, Николай, не хорошо . Особенно для менеджера — вы же у нас "слуга царю — отец солдатам", так?

Здравствуйте, IB, Вы писали:

A>>Слушай смешно же — я тоже сидел и хихикал.
IB>Да ладно? Что-то я сильно смешного там не углядел...
не потому ли что ты не был в толпе, а просматривал ролик индивидуально?

A>> Сидели там в основном люди которые далеко не разработчики и пришли посмотреть на шоу.
IB>У дядьки конечно presentation skills присутствуют в достаточном количестве,
не согласен ведь это же несколько противоречит следующему же выводу — если ему до профи далеко это в т.ч. означает что и соотв. умения несколько отстают, т.е. именно что недостаточны.

IB>но до настоящих профессионалов в этом деле ему далеко, только ради шоу на него ходить точно не стоит... =)
здесь два раза +1

до мастеров-ораторов не просто далеко, а еще дальше.
Шоу это также нечто более другое.

Здравствуйте, _Dinosaur, Вы писали:

_D>Все-таки реакция аудитории, действительно, выглядела странно.
Свое мнение почему реакция аудитории была именно такой отписал во второй ветке

Автор: Valery A. Boronin
Дата: 08.05.07

Здравствуйте, IB, Вы писали:

A>>Тем не менее по отзывам здесь и на job понял, что почти никто не понял про что хотел сказать Ашманов, ну и ладно.
IB>А он действительно хотел это сказать?
+1

A>>P.S. Подведу свое резюме как я его вижу: у него основной point(может не видно т.к. запись не полная) не то что процессы вредны и ими не надо пользоваться, а в том что они не достаточны и не являются целью сами по себе.
IB>Вот на этот поинт, там даже не намекается... Он просто рассказывает как все плохо, но ни слова не говорит о том что с этим делать. Когда он говорит о конкретных фактах, он вообщем-то не обманывает, но это все уже набившие оскомину банальности, которые не то что менеджеру — любому разработчику со стажем более полугода очевидны. А апломб в изложении банальностей — всегда вызывает негатив, так что реакция вполне закономерная. Тем более, что когда он начинает рассуждать о причинах сложившейся стуации и о своем отношении к этому, заносит его весьма конкретно.
+1

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

A>>"... тот кто начинает думать о бизнесе, его начинает тащить вверх просто законом архимеда ... если человек в состоянии быть менеджером это незамеченным не проходит никогда и его вытаскивает на верх всегда ..." (с) пересказ Anatolix

Автор: Anatolix
Дата: 19.04.07

тут каждый может это трактовать как ему угодно, вывод выше сделать можно, но он не будет точен для всех — это будет уже, скорее, личное сказано-то было все довольно обтекаемо — без конкретных виноватых-правых, в третьем лице — мол "не мы\вы такие а жизнь такая" — очень политкорректно

по мне так наоборот — была явная попытка сделать комплимент присутствующим — и судя по реакции она ожидаемо прошла успешно — уже отписался в др. ветке

Автор: Valery A. Boronin
Дата: 08.05.07

про это в т.ч.

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

IB>Все правильно говоришь, но это говоришь ты, а не Ашманов. А вот у Ашманова почему-то этой мысли не прослеживается ни в одном месте.
+1

Здравствуйте, Gaperton, Вы писали:

G>"Программисты не любят планоровать свой труд..." — гы, опять программеры виноваты в том, что усилиями менеджмента в компании не налажен сквозной процесс планирования и контроля . Смешно право слово. Планирование — это умение, этому надо учиться. Вот мы тренинги по планированию проводим — у нас в результате некоторые программисты владеют технологией планирования лучше, чем менеджмент соседних отделов.

А можно по подробнее? Что за тренинги?

Приветствую!

G>>Это для веб разработки — оной из самых простых областей разработки, у нас не работает Управление Проектами? Может, Ашманов просто не умеет готовить этих кошек? Просмотрел я в нескольких точках то выступление — то ли мне так повезло, но...

_D>Область простая, но быстроразвивающаяся и нестабильная, что определяет наличие дополнительных рисков.

Извините, а что значит "простая"? Или Вы считаете, что google, ebay, yahoo, fidelity — более простые в разработке проекты, чем произвольное десктопное приложение?
Снобизмом попахивает. Веб — приложение ничем не отличается от десктопного, если конечно Вы не сравниваете сложность реализации контент-сайта компании с операционной системой

Извините, но касательно веба очень поверхностный взгляд на вещи. Пообщайтесь с людьми, которые делали веб — ориентированные приложения с числом юз-кейсов больше нескольких сотен-тысяч и поймёте — те же яйца, только в профиль Лично я участвовал в проекте с числом юз-кейсов за 7 сотен на старте и, как обычно — жесточайшим дедлайном. Где тут простота?

С уважением

Здравствуйте, Gaperton, Вы писали:

G>Это для веб разработки — оной из самых простых областей разработки, у нас не работает Управление Проектами? Может, Ашманов просто не умеет готовить этих кошек? Просмотрел я в нескольких точках то выступление — то ли мне так повезло, но...

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

G>"Программисты совершенно аутичные личности..." — не понимает он программистов, вот что он нам хочет на самом деле сказать. Как можно ими руководить, не понимая их?

Всегда "уважал" людей, которые знают о чем думают или что на самом деле хотели сказать другие. Таких называют экстрасенсами.

G>"Программисты типо вместо кодирования хотят разработать общую платформу" — понятно, контроль над разработкой у Ашманова нулевой, в их процессе разработки нет связи между требованиями, дизайном, и кодированием. Программисты конечно опять в том виноваты, вовсе не менеджмент и не сам Ашманов.

Да, если у вас работают настоящие программисты, которые воспринимают свой труд как творчество, то именно так и будет. Они будут решать задачу, сложность которой почти всегда заведомо выше требуемой, просто потому что им это более интересно. Если ваши сотрудники пришли просто за зарплатой, т.е. цель отсидеть 8 часов рабочего дня, минимизировать при этом свои усилия и общий результат им вообще пофиг, то тогда вы абсолютно правы, такое стадо нужно контролировать очень и очень тщательно. Жаль, что планирование при этом привращается в игру "угадай кто меньше сделает".
Кстати, Ашманов очень явно делает акцент, на том, что программисты не виноваты в общем результате и это ВСЕГДА заслуга менеджмента. Вы внимательно смотрели и слушали выступление?

G>"Программисты не любят планоровать свой труд..." — гы, опять программеры виноваты в том, что усилиями менеджмента в компании не налажен сквозной процесс планирования и контроля . Смешно право слово. Планирование — это умение, этому надо учиться. Вот мы тренинги по планированию проводим — у нас в результате некоторые программисты владеют технологией планирования лучше, чем менеджмент соседних отделов.

G>"Программисты всегда называют сроки короче, я не разу не видел случая, когда было бы по другому..." — понятно, метрики с закрытых задач не снимаются, а так как процесс планирования не интегрирован в процесс разработки, программисты не имеют возможности учиться планированию .

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

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

Ашманов ни слова не сказал даже о виде бизнеса. А вам уже удалось сделать вывод, что исполнительный директор лишен деловых качеств. Т.е. определения "дела" еще даже НЕ БЫЛО, а вы уже человеку в качествах отказали... Быстро однако.

G>Короче говоря, у еня сложилось впечатление, что
G>1) Ашманов не понимает разработчиков, они для него загадочные личности
G>2) Не понимает, что такое организованный процесс разработки — впрочем, в российских компаниях этого традиционно не понимают
G>3) Либо не читал литературы, либо читал, но не в состоянии понять, о каких проблемах там вообще пишут. Вся его речь отдает самобытностью и доморощенностью. Для человека с опытом в индустрии года 3 — неплохо, но для такого взрослого дядьки — просто смешно.

Хорошо, что это только ваше впечатление. У меня тоже иногда складывается впечатление, что Билл Гейтс не понимает разработчиков. Вот меня бы на его место! И уж я бы ух! И почему я не Билл Гейтс . А то ведь все вокруг самобытные и доморощенные, а я умный такой и столько книжек прочитал и понял все правильно ... но всем как-то пофиг .

G>Особенно радуют аплодисменты аудитории, когда Ашманов очередную глупость про непонятных ему программистов говорит.

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

Здравствуйте, damiano, Вы писали:

D>Приветствую!

G>>>Это для веб разработки — оной из самых простых областей разработки, у нас не работает Управление Проектами? Может, Ашманов просто не умеет готовить этих кошек? Просмотрел я в нескольких точках то выступление — то ли мне так повезло, но...

_D>>Область простая, но быстроразвивающаяся и нестабильная, что определяет наличие дополнительных рисков.

D>Извините, а что значит "простая"? Или Вы считаете, что google, ebay, yahoo, fidelity — более простые в разработке проекты, чем произвольное десктопное приложение?
Нет, я считаю, что клиенты баз данных, типичные десктопные приложения с формочками и бизнес-логика на вебе в готовой инфраструктуре немного так попроще кастомных приложений таких, как МС SQL Server, САПРы, Ворд, Эксель, Полверпойнт, и прочих, где готовой инфраструктуры не используется. Есть целый мир, в котором приложения не собираются из кубиков и в котором понятию "бизнес-логика" не уделяют такого большого внимания — есть и другие проблемы. В этом мире разработка обходится гораздо большей кровью и потом.

Вот ты взял гугл и ебай. Это принципиально разные проекты — гугль сложнее ебая, который сделан на йаве и веблоджике, если мне память не изменяет. Гугль же использует собственную инфраструктуру.

D>Снобизмом попахивает. Веб — приложение ничем не отличается от десктопного, если конечно Вы не сравниваете сложность реализации контент-сайта компании с операционной системой
Веб-приложение ничем не отличается от клиент-серверного приложения баз данных. И то и другое — является наиболее простой областью разработки — она ведется на готовых фреймворках и сервисах. Это не снобизм, это правда.

D>Извините, но касательно веба очень поверхностный взгляд на вещи. Пообщайтесь с людьми, которые делали веб — ориентированные приложения с числом юз-кейсов больше нескольких сотен-тысяч и поймёте — те же яйца, только в профиль Лично я участвовал в проекте с числом юз-кейсов за 7 сотен на старте и, как обычно — жесточайшим дедлайном. Где тут простота?

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

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, damiano, Вы писали:

D>>Приветствую!

G>>>>Это для веб разработки — оной из самых простых областей разработки, у нас не работает Управление Проектами? Может, Ашманов просто не умеет готовить этих кошек? Просмотрел я в нескольких точках то выступление — то ли мне так повезло, но...

_D>>>Область простая, но быстроразвивающаяся и нестабильная, что определяет наличие дополнительных рисков.

D>>Извините, а что значит "простая"? Или Вы считаете, что google, ebay, yahoo, fidelity — более простые в разработке проекты, чем произвольное десктопное приложение?
А>Нет, я считаю, что клиенты баз данных, типичные десктопные приложения с формочками и бизнес-логика на вебе в готовой инфраструктуре немного так попроще кастомных приложений таких, как МС SQL Server, САПРы, Ворд, Эксель, Полверпойнт, и прочих, где готовой инфраструктуры не используется. Есть целый мир, в котором приложения не собираются из кубиков и в котором понятию "бизнес-логика" не уделяют такого большого внимания — есть и другие проблемы. В этом мире разработка обходится гораздо большей кровью и потом.

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

А>Вот ты взял гугл и ебай. Это принципиально разные проекты — гугль сложнее ебая, который сделан на йаве и веблоджике, если мне память не изменяет. Гугль же использует собственную инфраструктуру.

D>>Снобизмом попахивает. Веб — приложение ничем не отличается от десктопного, если конечно Вы не сравниваете сложность реализации контент-сайта компании с операционной системой
А>Веб-приложение ничем не отличается от клиент-серверного приложения баз данных. И то и другое — является наиболее простой областью разработки — она ведется на готовых фреймворках и сервисах. Это не снобизм, это правда.

а кто разрабатывает, по-вашему, готовые фреймворки и сервисы? боги?
а разработчики гугла, юзая бигтейбл и мапредьюс — скатываются ли они до банальных кубикособирателей?

D>>Извините, но касательно веба очень поверхностный взгляд на вещи. Пообщайтесь с людьми, которые делали веб — ориентированные приложения с числом юз-кейсов больше нескольких сотен-тысяч и поймёте — те же яйца, только в профиль Лично я участвовал в проекте с числом юз-кейсов за 7 сотен на старте и, как обычно — жесточайшим дедлайном. Где тут простота?

А>Простота в том, что вы в основном комбинируете чужие технологии, а не изобретаете собственные. Все основные проблемы решены за вас разработчиками фреймворков и сервисов, которыми вы пользуетесь. Делать проекты такие с инженерной точки зрения — так же сложно, там есть свои сложности, но с точки зрения менеджмента они тривиальны. Они типовые, ими можно управлять практически по шаблону. Проекты разработки кастом-приложений — уникальны, непохожи друг на друга, там сложности каждый раз разные, и ничего, управление проектами работает. В этом пойнт, а не в том, что разработка веб-приложений не требует мозгов. Требует конечно.

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

как раз фреймворки и сервисы я и делал (до ухода в менеджерство) и я знаю, что ниоткуда они не берутся

шаблон — не согласен, метода — да, есть такое, но для этого она и нужна, так ведь?

веб — приложения тоже иногда бывают кастом и никаких кубиков — все с нуля

с уважением

Здравствуйте, damiano, Вы писали:

D>Приветствую!
Доброго времени суток!

_D>>Область простая, но быстроразвивающаяся и нестабильная, что определяет наличие дополнительных рисков.
D>Извините, а что значит "простая"?

Можно сказать по-другому: относительно простая...
Например, если сравнивать с созданием какого-нибудь программно-аппаратного комплекса.

D>Извините, но касательно веба очень поверхностный взгляд на вещи. Пообщайтесь с людьми, которые делали веб — ориентированные приложения с числом юз-кейсов больше нескольких сотен-тысяч и поймёте — те же яйца, только в профиль Лично я участвовал в проекте с числом юз-кейсов за 7 сотен на старте и, как обычно — жесточайшим дедлайном. Где тут простота?

Общаясь со знакомыми PM-и (с теми, кто работает с веб-технологиями), я почти не слышал от них о технологических сложностях (рисках) проектов, а основные озвучиваемые ими проблемы были связаны со сжатыми сроками и большими объемами работ. Это же находим и в цитируемом абзаце.

D>С уважением
взаимно

Здравствуйте, _Dinosaur, Вы писали:

_D>Здравствуйте, damiano, Вы писали:

D>>Приветствую!
_D>Доброго времени суток!

Доброго и Вам!

_D>>>Область простая, но быстроразвивающаяся и нестабильная, что определяет наличие дополнительных рисков.
D>>Извините, а что значит "простая"?

_D>Можно сказать по-другому: относительно простая...
_D>Например, если сравнивать с созданием какого-нибудь программно-аппаратного комплекса.

Трудно сравнивать по уровню сложности абсолютно разные задачи Это как женщин сравнивать — не может быть одна априори лучше/хуже другой — они разные.

D>>Извините, но касательно веба очень поверхностный взгляд на вещи. Пообщайтесь с людьми, которые делали веб — ориентированные приложения с числом юз-кейсов больше нескольких сотен-тысяч и поймёте — те же яйца, только в профиль Лично я участвовал в проекте с числом юз-кейсов за 7 сотен на старте и, как обычно — жесточайшим дедлайном. Где тут простота?

_D>Общаясь со знакомыми PM-и (с теми, кто работает с веб-технологиями), я почти не слышал от них о технологических сложностях (рисках) проектов, а основные озвучиваемые ими проблемы были связаны со сжатыми сроками и большими объемами работ. Это же находим и в цитируемом абзаце.

Я приводил примеры проектов с числом юз-кейсов, зашкаливающих за тысячу или нетривиальной бизнес-моделью или технологическим решением (базы с полиморфной моделью, например)- там рисков на фазе архитектурирования именно технологических — выше крыши Поэтому и технико-экономические обоснования применяемых технологий и решений занимают массу времени на рисёрч и анализ
Сами знаете — сейчас в веб приходит масса бизнес — моделей, которые ранее были чисто оффлайновыми. Возьмём, например, финансы, симуляторы — экономические, спортивные и т.д. По симуляторам — сами знаете уровень сложности матаппарата и техреализации — нейронные сети, нейронная память, прогнозирование и т.д. Сейчас уже трудно, зачастую, отделить веб решение от софтового
Достаточно сложные задачи приходится решать сейчас в веб-отрасли. Поисковые и крупные статсистемы — тоже уже не новость, web-based ERP-системы — уже появляются. Масса всего не совсем простого

С уважением

Здравствуйте, C0deKhan, Вы писали:

CK> Вы не могли бы назвать все области разработки, в которых вы участвовали (подчеркиваю — только ваш личный опыт), и проранжировать их по степени сложности.
Демагогия на грани фола, почитай правила (строфа "обязательные правила", стих пятый), и впредь постарайся подобных промашек не допускать.

CK>Всегда "уважал" людей, которые знают о чем думают или что на самом деле хотели сказать другие. Таких называют экстрасенсами.
Если автор не смог донести свою мысль так чтобы его поняли, приходится заниматься экстрасенсорной практикой.

CK>Кстати, Ашманов очень явно делает акцент, на том, что программисты не виноваты в общем результате и это ВСЕГДА заслуга менеджмента.
Что-то этот акцент ускользнул от большинства чутких слушателей.

CK>Ашманов ни слова не сказал даже о виде бизнеса.
То есть, ты знаешь такой вид бизнеса в котором игнорирование неустраивающих сотрудников ни как не влияет на деловые качества?

CK>Глупая аудитория аплодирует глупому Ашманову, который говорит глупости о программистах.
Увы... Этот факт печалит больше всего.

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

Здравствуйте, damiano, Вы писали:

G>>>>>Это для веб разработки — оной из самых простых областей разработки, у нас не работает Управление Проектами? Может, Ашманов просто не умеет готовить этих кошек? Просмотрел я в нескольких точках то выступление — то ли мне так повезло, но...

_D>>>>Область простая, но быстроразвивающаяся и нестабильная, что определяет наличие дополнительных рисков.

D>>>Извините, а что значит "простая"? Или Вы считаете, что google, ebay, yahoo, fidelity — более простые в разработке проекты, чем произвольное десктопное приложение?
А>>Нет, я считаю, что клиенты баз данных, типичные десктопные приложения с формочками и бизнес-логика на вебе в готовой инфраструктуре немного так попроще кастомных приложений таких, как МС SQL Server, САПРы, Ворд, Эксель, Полверпойнт, и прочих, где готовой инфраструктуры не используется. Есть целый мир, в котором приложения не собираются из кубиков и в котором понятию "бизнес-логика" не уделяют такого большого внимания — есть и другие проблемы. В этом мире разработка обходится гораздо большей кровью и потом.

D>вы меня конкретно удивили... т.е. каждый из продуктов мс офиса имеет собственную, уникальную инфраструктуру?
Удивительное рядом, коллега. Разумеется, семейство программ MS Office разрабатывается как семейство, с единой инфораструктурой. Но дело не в этом. Дело в том, что
1) В проект разработки оффиса закладывается и разработка инфраструктуры для него — никто за МС это не сделает, что для подавляющего большинства веб-приложений не так — они полагаются на готовую инфраструктуру сторонней разработки.
2) Помимо проекта по разработке стандатной инфраструктуры разаботка логики таких приложений как Excel — даст фору по сложности подавляющему большинству веб-приложений (да и десктопных тоже) из-за сильно кастомной ГУИ, не ложащейся на фреймворки, и уникального, не являющегося частью инфрасруктуры, движка обработки данных.

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

D>касательно бизнес — логики — не лукавьте, батенька, помянутый всуе ворд делался не ради кастомной инфраструктуры и не для того, чтобы сделать что-то не "из кубиков", а с конкретной целью — захватить рынок текстовых процессоров или я не прав?

Любое коммерческое приложение делается с целью его продать, и "захватить рынок", а не с целью сделать что-то их кубиков. Ворд не помянут всуе, а приведен в качестве примера. А вы начали петлять и прикидываться, что не понимаете, о чем речь. Ну, не понимаете — значит не судьба.

А>>Вот ты взял гугл и ебай. Это принципиально разные проекты — гугль сложнее ебая, который сделан на йаве и веблоджике, если мне память не изменяет. Гугль же использует собственную инфраструктуру.

D>>>Снобизмом попахивает. Веб — приложение ничем не отличается от десктопного, если конечно Вы не сравниваете сложность реализации контент-сайта компании с операционной системой
А>>Веб-приложение ничем не отличается от клиент-серверного приложения баз данных. И то и другое — является наиболее простой областью разработки — она ведется на готовых фреймворках и сервисах. Это не снобизм, это правда.

D>а кто разрабатывает, по-вашему, готовые фреймворки и сервисы? боги?
Отдельные компании и коллективы разработчиков. Разработку таких проектов как Web-logic, MySQL, и Apache с любой натяжкой веб-разработкой назвать нельзя. ти компании и коллективы разрабатывают технологии. Подавляющее большинство веб-проектов их комбинируют. Так устроен современный мир — там правит балом разделение труда и feed chain.

D>а разработчики гугла, юзая бигтейбл и мапредьюс — скатываются ли они до банальных кубикособирателей?
У гугла своя инфраструктура, собственной разработки. Какие-то сторонние технологии применют и они — тот же линух, например, и это нормально. Хотя, у них даже свой дистрибутев линуха есть для себя (gubuntu). Однако, ключевые технологии, специфичные для их бизнеса, они разрабатывают сами — например, распределенная файловая система собственной разработки, и собственный поисковый движок.

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

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

D>>>Извините, но касательно веба очень поверхностный взгляд на вещи. Пообщайтесь с людьми, которые делали веб — ориентированные приложения с числом юз-кейсов больше нескольких сотен-тысяч и поймёте — те же яйца, только в профиль Лично я участвовал в проекте с числом юз-кейсов за 7 сотен на старте и, как обычно — жесточайшим дедлайном. Где тут простота?

А>>Простота в том, что вы в основном комбинируете чужие технологии, а не изобретаете собственные. Все основные проблемы решены за вас разработчиками фреймворков и сервисов, которыми вы пользуетесь. Делать проекты такие с инженерной точки зрения — так же сложно, там есть свои сложности, но с точки зрения менеджмента они тривиальны. Они типовые, ими можно управлять практически по шаблону. Проекты разработки кастом-приложений — уникальны, непохожи друг на друга, там сложности каждый раз разные, и ничего, управление проектами работает. В этом пойнт, а не в том, что разработка веб-приложений не требует мозгов. Требует конечно.

D>смысл создания приложения, на мой взгляд — не изобреиение технологий, а решение бизнес — задач. технологии — инструмент. выполненные бизнесовые задачи — источник денег, а не технологии
Ага. И что?

D>как раз фреймворки и сервисы я и делал (до ухода в менеджерство) и я знаю, что ниоткуда они не берутся
Так. Вы делали фреймворки. Классно. И?

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

D>веб — приложения тоже иногда бывают кастом и никаких кубиков — все с нуля
Редко. До чрезвычайности редко. Во-первых, в чистом вебе нельзя делать owner-draw и управлять отрисовкой. До сих пор не существует ни одного веб-приложения, хотя бы сопоставимого по сложности ГУИ и логики с офисным приложением.

Здравствуйте, Gaperton, Вы писали:

G>Здравствуйте, damiano, Вы писали:


Значит Аноним тождественно равно Gaperton? Извините, отвечать по контексту не буду — Вы слишком язвительны, иронии не понимаете, воспринимаете все буквально и близко к сердцу Из уважения к Вам предлагаю закрыть вопрос. Согласен, что разработка СУБД и ERP-системы, использующей эту СУБД — принципиально разные вещи. Но я всё-таки считаю, что говорить о том, что одна область проще, а другая легче — не всегда корректно. Они разные и риски разные.

С уважением

Здравствуйте, damiano, Вы писали:

D>Сами знаете — сейчас в веб приходит масса бизнес — моделей, которые ранее были чисто оффлайновыми. Возьмём, например, финансы, симуляторы — экономические, спортивные и т.д. По симуляторам — сами знаете уровень сложности матаппарата и техреализации — нейронные сети, нейронная память, прогнозирование и т.д. Сейчас уже трудно, зачастую, отделить веб решение от софтового

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