А где все наши программисты?

[bizon2007]

переведи

 

[Aleksandrkh]

Да все раб-отают на запад эт 100%

 

[neocortex]

Основная концепция ООП - строим из кирпичей.
Планируем так, что бы кирпичи можно было менять.

ООП - оно для компьютерных программ, а мы, вроде как, о ЛЮДЯХ.

Поручик, ну вот в самом деле, вам лично удалось успешно завершить хоть один более-менее сложных проект, пользуясь пропагандируемым вами же подходом? Я ни в коем случае не хочу переводить разговор в стиль "сам *****", но сравнение организации работы проектной команды с ООП - очень подмывает уточнить - вы теоретик или практик?

 

[neocortex]

Грамотный проект - он не на людях держится. Когда проект зависит от людей, то этот проект - ****о и его руководитель - *****.

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

 

[neocortex]

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

В конкретно этой теме есть как минимум два человека, которым пустить пыль в глаза будет достаточно непросто.

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

"Считать подход правильным" и реально успешно (!) применять его на практике - две очень, как говорят в Одессе, большие разницы. И именно поэтому мне очень любопытно, как вы (или ваш босс, если вы и есть этот самый мозговой центр) боретесь с риском потери мозгового центра, который, собственно, и занимается грамотным распределением работ?

Для примера, вводная: Приходит к вам завтра ваш головастый Вася Пупкин и говорит "Все, босс, достало пасти хомячков - увольняюсь, отрабатываю две недели (или сколько у вас полагается) - и адью!". Проходят эти самые две недели, а на третей, как назло, объявляется заказчик и меняет половину требований. Ваши действия?

 

[sergeime]

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

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

Давай, напусти мне пыльцы в глаза или может сразу ***ми померяемся?

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

С R'n'D проектами - вообще никакой подход не работает. Там requirements по 2 раза в день меняются - хомячкам совсем делать нечего, они соображать не успевают как правило.

 

[bizon2007]

Для примера, вводная: Приходит к вам завтра ваш головастый Вася Пупкин и говорит "Все, босс, достало пасти хомячков - увольняюсь, отрабатываю две недели (или сколько у вас полагается) - и адью!". Проходят эти самые две недели, а на третей, как назло, объявляется заказчик и меняет половину требований. Ваши действия?

*********** заказчика

 

[Orshansky]

Я ни в коем случае не хочу переводить разговор в стиль "сам *****", но сравнение организации работы проектной команды с ООП - очень подмывает уточнить - вы теоретик или практик?

С R'n'D проектами - вообще никакой подход не работает. Там requirements по 2 раза в день меняются - хомячкам совсем делать нечего, они соображать не успевают как правило

Встречный вопрос, вы что то сложнее клиент-серверных приложений на .NET разрабатывали?

Для примера, вводная: Приходит к вам завтра ваш головастый Вася Пупкин и говорит "Все, босс, достало пасти хомячков - увольняюсь, отрабатываю две недели (или сколько у вас полагается) - и адью!". Проходят эти самые две недели, а на третей, как назло, объявляется заказчик и меняет половину требований. Ваши действия?

Та даже если не уходит, а скажем тяжело заболел? Если у вас в процессе разработки нет взаимозаеняемости кадров - грошь цена вам как руководителю.

 

[neocortex]

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

Сам-то чьих будешь, умный ты наш? 10 лет только коммерческого опыта в IT не хотел? А у sergeime наверное и поболее будет...

Встречный вопрос, вы что то сложнее клиент-серверных приложений на .NET разрабатывали?

То есть, "автор какбе намекает", что действительно грамотно спроектировать и написать масштабируемое серверное приложение с надежностью хотя бы 99.3% - ему как два пальца об асфальт? Или к чему эта сентенция была? Тем более, с подтекстом, что, мол ".NET - это не труъ"

Давайте все же не путать х... с пальцем разрабатываемые сообществом open-source проекты и коммерческую разработку под заказ, ага? Бизнес-модели слишком уж разные. Кстати, разбиение больших проектов на подпроекты и feature teams никто не оспаривал, если ты об этом.

Та даже если не уходит, а скажем тяжело заболел? Если у вас в процессе разработки нет взаимозаеняемости кадров - грошь цена вам как руководителю.

Я полагаю, эта часть ответа адресована Поручику? От себя добавлю, что полная взаимозаменяемость кадров она это... далеко не всегда достижима, даже при более чем вменяемом руководителе уровня PM'а. Но, согласен - "один гуру плюс много хомячков" - уж ОЧЕНЬ рискованная схема.

 

[Orshansky]

То есть, "автор какбе намекает", что действительно грамотно спроектировать и написать масштабируемое серверное приложение с надежностью хотя бы 99.3% - ему как два пальца об асфальт? Или к чему эта сентенция была? Тем более, с подтекстом, что, мол ".NET - это не труъ"

Вы вообще в курсе, что например операторы связи в Мире, с клиентами подписывают договора с оговоренным SLA на уровне 99.5%, 99.9%... Так, что если разрабатываемые вами системы имеют надежность 99.3%, то спасибо, вы ответили на вопрос.

Давайте все же не путать х... с пальцем разрабатываемые сообществом open-source проекты и коммерческую разработку под заказ, ага? Бизнес-модели слишком уж разные. Кстати, разбиение больших проектов на подпроекты и feature teams никто не оспаривал, если ты об этом.

Бред.

Эти проекты спонсируются гараздо больше чем ваши мелкие поделки с надежностью 99.3% с периодическими core dump.

Я полагаю, эта часть ответа адресована Поручику? От себя добавлю, что полная взаимозаменяемость кадров она это... далеко не всегда достижима, даже при более чем вменяемом руководителе уровня PM'а. Но, согласен - "один гуру плюс много хомячков" - уж ОЧЕНЬ рискованная схема.

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

 

[Ferox]

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

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

В конечном итоге хозяину начхать даже на любого отдельно взятого заказчика (если это не контора одного проекта). Ему надо обеспечить общую рентабельность всей деятельности в целом.

 

[Ferox]

P.S. Сказанное относится прежде всего к neocortex и Orshansky, мне кажется они чересчур заостряются на производственных вопросах и интересах клиента, и забывают об интересах владельца конторы производящей программный продукт.

 

[Ferox]

Здесь действует принцип мультипликативности.
Если успешно выполнен один проект, то шансы каждого последующего увеличиваются.
Успешные проекты - бонусы и бабки

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

 

[neocortex]

Вы вообще в курсе, что например операторы связи в Мире, с клиентами подписывают договора с оговоренным SLA на уровне 99.5%, 99.9%

На мой вопрос вы так и не ответили, сославшись на неких мифических операторов связи. Затем, вы, надеюсь, достаточно четко осознаете разницу в надежности, обеспечиваемой только программными и программно-аппаратными средствами? Могу ошибаться в десятых долях процента, но без failover кластеров/"горячего резерва" надежность выше чем ~99.3% попросту недостижима. Причем, в основном эти 0.7% относятся как раз к сбоям аппаратуры, т.е. для для достижения ХОТЯ БЫ 99.3% именно софт должен работать идеально, "без единого разрыва".

Эти проекты спонсируются гараздо больше чем ваши мелкие поделки с надежностью 99.3% с периодическими core dump.

Если вы хотите предметной дискуссии, а не флейма (в котором я участвовать не намерен), то настоятельно рекомендую сменить тон "мелкие поделки" на более конструктивный. Тем более, вы уж определитесь - core dump или .NET ? А то "смешались в кучу, кони, люди". И, наконец, бюджет - это не единственный показатель бизнес-модели, ага?

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

Смотря о каком уровне взаимозаменяемости мы говорим и о каком размере команды. В команде, скажем, 5-7 человек, держать лишнего senior'а "про запас" в бизнес-модели аутсорсинга, особенно если клиента биллят по блендед-рейту, никто не будет.

HR риски в проектном управлении минимизируются путем разложения сложной задачи на более простые

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

избыточностью

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

и ротацией ролей персонала в коллективе.

Если мы исходим из посылки, что у "хомячков" analytical skills отсутствуют по определению, то как, по-вашему, будет работать ротация? Нет, можно, конечно, периодически тасовать лидов / ПМов между проектами, но я еще ни разу не видел на практике, чтобы так делали - и, очевидно, на то есть причины.

Все вышесказанное - прописные истины. которые расказываются студентам на лекциях по pmbok.
За непрописными истинами пожалуйста на платный треннинг.

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

 

[sergeime]

Вы вообще в курсе, что например операторы связи в Мире, с клиентами подписывают договора с оговоренным SLA на уровне 99.5%, 99.9%... Так, что если разрабатываемые вами системы имеют надежность 99.3%, то спасибо, вы ответили на вопрос.

Эти проекты спонсируются гараздо больше чем ваши мелкие поделки с надежностью 99.3% с периодическими core dump.

Если это более не секретная информация, то neocortex думаю сможет рассказать какая именно надежность есть у системы, он знает у какой.

 

[neocortex]

на многие рынки вход неуспешным компаниям закрыт.

Если компания провалила 10 проектов по 10к$ и выполнила 100 проектов по 100k$, то все будут знать о ее % брака, который составит 10%.

Интересно только, кто эти "все"? Руководство компании же, не будь *****ами, наверняка даже в случае эпик фейла стараются решить вопрос полюбовно - обходится недешево, но репутация дороже. Да, клиент проваленного проекта, конечно, не порекомендует компанию своим друзьям, но с большой вероятностью эти друзья будут из категории "10k$", что не помешает сейлзам успешно "окучивать" более крупную рыбу, пуская пыль в глаза case study как раз по тем успешным проектам за 100 килобаксов.

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

 

[Orshansky]

На мой вопрос вы так и не ответили, сославшись на неких мифических операторов связи. Затем, вы, надеюсь, достаточно четко осознаете разницу в надежности, обеспечиваемой только программными и программно-аппаратными средствами? Могу ошибаться в десятых долях процента, но без failover кластеров/"горячего резерва" надежность выше чем ~99.3% попросту недостижима. Причем, в основном эти 0.7% относятся как раз к сбоям аппаратуры, т.е. для для достижения ХОТЯ БЫ 99.3% именно софт должен работать идеально, "без единого разрыва".

Бред.

Вообще вы говорили о нажедности программного обеспечения, а не программно-аппаратного комплекса. У вас в коде может быть элементарная логическая ошибка, ну к примеру неверное приведение типов, деление на ноль... В результате чего программа будет работать "без единого разрыва", но так как свои функции такое ПО не будет выполнять, то надежность вашего ПО будет ниже плинтуса.

Надежность же программно-аппаратного комплекса в целом расчитывается исходя из надежности его составляющие по не сложной формуле. Поинтересуйтесь. Ну к примеру, известная всем компания Juniper допустив фатальную ошибку в коде файервола (специфический TCP пакет приводил к ошибке памяти на стороне ядра JunOS) на аппаратной платформе с надежностью 99.99% и временем готовности 99.999...% привела к тому, что один из всемирно известных операторов связи не мог восстановить работу в течении нескольких суток. Поэтому когда говорят о надежности свыше 99.5%, то как правило резервируют не только программные и аппаратные средства, но и вендоров, в нашем случае компнии разрабатывающие ПО.

Если вы хотите предметной дискуссии, а не флейма (в котором я участвовать не намерен), то настоятельно рекомендую сменить тон "мелкие поделки" на более конструктивный. Тем более, вы уж определитесь - core dump или .NET ? А то "смешались в кучу, кони, люди".

Именно core dump .NET + mono, в Win32 minidump... Вам бы кругозор расширить.

Смотря о каком уровне взаимозаменяемости мы говорим и о каком размере команды. В команде, скажем, 5-7 человек, держать лишнего senior'а "про запас" в бизнес-модели аутсорсинга, особенно если клиента биллят по блендед-рейту, никто не будет.

Полная или частичная взаимозаменяемость появляется в команде состоящей как минимум из двух человек.

 

[sergeime]

Бред.

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

Ты наверное не в курсе что софт обычно тестят. Причем иногда так тестят что девелопить некогда.

 

[Orshansky]

Ты наверное не в курсе что софт обычно тестят. Причем иногда так тестят что девелопить некогда.

см. выше. к вопросу о надежности и Juniper.

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

Ну возьмем другую компанию, разработчика ПО:

CSCsx63557

When Layer 2 Tunnel Protocol (L2TP) sessions are created and then torn down by Intelligent Services Gateway (ISG), the Cisco QuantumFlow Processor (QFP) leaks DRAM memory.

There are no known workarounds.

•CSCsx63585

On a Cisco ASR 1000 Series Router, the repeated set-up and teardown of large numbers of Intelligent Services Gateway (ISG) sessions over the Layer 2 Tunnel Protocol (L2TP) results in a memory leak on the Embedded Services Processor (ESP). The leak is small, and no service impact is expected under normal operating conditions.

There are no known workarounds.

⚠ Тільки зареєстровані користувачі бачать весь контент та не бачать рекламу.

 

[sergeime]

см. выше. к вопросу о надежности и Juniper.

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

У тебя священный ужас перед .NET? На чем прикажешь их писать, на пхп?

Тестирование - оно разное бывает. Ты просто не в курсе.