Аналитический клуб

Аналитический Клуб => Общение с администрацией => Тема начата: ALEXandr от 19 Октябрь 2006, 09:23:23

Название: Архив Е.В.
Отправлено: ALEXandr от 19 Октябрь 2006, 09:23:23
Цитировать
Net, ne zapustili.
Ushe 10-y programmist ne sposoben ni modernizirovat' dvijok Buly4eva, ni sdelat' novyj kloniruemyj hotja by polovinnoj funkcionalnosti.
Dumaju, tut delo ne prosto v neverojatnoj tuposti nyneschnego pokolenija programmistov. Esli voznikajut takie prepjatstvija na protjajenii 2h let, zna4it - Gospod' ne ho4et, 4toby byli novye saity. I huj s nim: hvatit suschestvujuschih
Честно говоря не верю что так уж сложно разобраться с движком.
Может им мало платите? ;)

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

Обратная сторона популярности.
Название: Архив Е.В.
Отправлено: Колобок от 19 Октябрь 2006, 10:35:41
Ерунда, это значит всего лишь то, что код Булычёва трудно читаем. Надо писать с нуля по новой.
Название: Архив Е.В.
Отправлено: avl от 19 Октябрь 2006, 12:33:24
У меня вот тоже даже простешие программы с трудом идут, хотя я профессиональный программист. Может господь и вправду к программам не очень благоволит? :)
Название: Архив Е.В.
Отправлено: vvk от 19 Октябрь 2006, 15:04:28
Цитировать
У меня вот тоже даже простешие программы с трудом идут, хотя я профессиональный программист. Может господь и вправду к программам не очень благоволит? :)
Может господь хочет, чтобы программисты перешли на декларативные языки и среды программирования? :)
Название: Архив Е.В.
Отправлено: Колобок от 19 Октябрь 2006, 15:38:34
Цитировать
Цитировать
У меня вот тоже даже простешие программы с трудом идут, хотя я профессиональный программист. Может господь и вправду к программам не очень благоволит? :)
Может господь хочет, чтобы программисты перешли на декларативные языки и среды программирования? :)
Господь хочет, чтобы он перестал заниматься программированием и занялся чем-то, к чему лежит душа и способности :)
Название: Архив Е.В.
Отправлено: Flammar от 19 Октябрь 2006, 16:16:14
Цитировать
Цитировать
Цитировать
У меня вот тоже даже простешие программы с трудом идут, хотя я профессиональный программист. Может господь и вправду к программам не очень благоволит? :)
Может господь хочет, чтобы программисты перешли на декларативные языки и среды программирования? :)
Господь хочет, чтобы он перестал заниматься программированием и занялся чем-то, к чему лежит душа и способности :)
Терроризмом или другим криминалом, например...
Название: Архив Е.В.
Отправлено: t_vitali от 20 Октябрь 2006, 06:27:36
Вообще народ - кто нибудь в скриптах пробовал разбираться? Особенно если скрипты  писал гений одиночка? Млин...
Если код писался не соблюдая стандартов, тем более скрипты, то обычно легче старый код на хер выбросить и новый написать. Это давно известная проблема и она решаема - по пальцам железной линейкой. Для того что бы таких косяков не было - пишут группами, + обязательное ведение документации, + постоянные код ревью и ещё много всякой всячины (такой как планы развития с описанием фичеров, Source Safe - чтобы можно было бы отслеживать изменения, вести версии, тестирование и т.д.). Это уже технология господа - Software Development называется. То есть должны быть организованны процессы в рамках проекта. А когда всё отдаётся на откуп одному человеку, тем более гению, когда он исчезает - проект рушится. ШЭЛ не первый кто на эти грабли наступил.
ШЭЛ сам по себе проект большой. Когда то можно было что то на коленке нацарапать и это работало. Но вот с изменениями и расширением проблемы. Это результат отсуцтвия менеджмента и просто технологии.
Моя мысль такая - не зачем свой не профессионализм и отсутствие опыта списывать на Господа. Он лишь указывает - ШЕЛ проэкт большой и серьёзный. Поэтому требует серьёзного к себе отношения. Господь говорит - измени отношение и сделай шаг вперёд. Перестань ШЭЛ воспринимать легко.
Нужна команда которая будет проект развивать или поддерживать. Нужен менеджер. Идеальный вариант нанять фирму, что бы систему управления контентом написали по уму и с документацией. Потом пусть админ - администрирует, а контора дописывает фичеры.
Название: Архив Е.В.
Отправлено: Flammar от 20 Октябрь 2006, 11:57:43
Цитировать
Вообще народ - кто нибудь в скриптах пробовал разбираться? Особенно если скрипты  писал гений одиночка? Млин...
Если код писался не соблюдая стандартов, тем более скрипты, то обычно легче старый код на хер выбросить и новый написать. Это давно известная проблема и она решаема - по пальцам железной линейкой. Для того что бы таких косяков не было - пишут группами, + обязательное ведение документации, + постоянные код ревью и ещё много всякой всячины (такой как планы развития с описанием фичеров, Source Safe - чтобы можно было бы отслеживать изменения, вести версии, тестирование и т.д.). Это уже технология господа - Software Development называется. То есть должны быть организованны процессы в рамках проекта. А когда всё отдаётся на откуп одному человеку, тем более гению, когда он исчезает - проект рушится. ШЭЛ не первый кто на эти грабли наступил.
ШЭЛ сам по себе проект большой. Когда то можно было что то на коленке нацарапать и это работало. Но вот с изменениями и расширением проблемы. Это результат отсуцтвия менеджмента и просто технологии.
Моя мысль такая - не зачем свой не профессионализм и отсутствие опыта списывать на Господа. Он лишь указывает - ШЕЛ проэкт большой и серьёзный. Поэтому требует серьёзного к себе отношения. Господь говорит - измени отношение и сделай шаг вперёд. Перестань ШЭЛ воспринимать легко.
Нужна команда которая будет проект развивать или поддерживать. Нужен менеджер. Идеальный вариант нанять фирму, что бы систему управления контентом написали по уму и с документацией. Потом пусть админ - администрирует, а контора дописывает фичеры.
Чем критиковать, лучше денег дай ;) . Сколько там надо на такую нормальную работу - 5 месяцев * 5 человек * 1,5 штуки в месяц каждому = 40 штук на новый движок (с гарантией 50%)?
Название: Архив Е.В.
Отправлено: AlexD от 20 Октябрь 2006, 13:37:42
Цитировать
Чем критиковать, лучше денег дай ;) . Сколько там надо на такую нормальную работу - 5 месяцев * 5 человек * 1,5 штуки в месяц каждому = 40 штук на новый движок (с гарантией 50%)?
От требований зависит. Но исходя из моего опыта:
3 месяца (max) * 2 человека (max) * как договоришься (вилка думаю от 500 - 1500) = 3000 - 9000 (с вероятностью 90%, если нормально контролировать процесс, а не забить на него и только спрасить результат спустя 3 месяца).
Название: Архив Е.В.
Отправлено: Father от 20 Октябрь 2006, 14:31:18
Цитировать
Цитировать
Чем критиковать, лучше денег дай ;) . Сколько там надо на такую нормальную работу - 5 месяцев * 5 человек * 1,5 штуки в месяц каждому = 40 штук на новый движок (с гарантией 50%)?
От требований зависит. Но исходя из моего опыта:
3 месяца (max) * 2 человека (max) * как договоришься (вилка думаю от 500 - 1500) = 3000 - 9000 (с вероятностью 90%, если нормально контролировать процесс, а не забить на него и только спрасить результат спустя 3 месяца).
А чем плохо купить готовый движок? Вроде их куча.
Название: Архив Е.В.
Отправлено: Flammar от 20 Октябрь 2006, 17:46:55
Цитировать
Цитировать
Чем критиковать, лучше денег дай ;) . Сколько там надо на такую нормальную работу - 5 месяцев * 5 человек * 1,5 штуки в месяц каждому = 40 штук на новый движок (с гарантией 50%)?
От требований зависит. Но исходя из моего опыта:
3 месяца (max) * 2 человека (max) * как договоришься (вилка думаю от 500 - 1500) = 3000 - 9000 (с вероятностью 90%, если нормально контролировать процесс, а не забить на него и только спрасить результат спустя 3 месяца).
Тогда еще и контролера нанимать...
Название: Архив Е.В.
Отправлено: druidm от 21 Октябрь 2006, 23:41:13
Повешайте ТЗ
и кто может или хочет или кого-то может посоветовать, Вам напишет
сколько нужно времени и денег, чтобы сделать(купить, установить) софтину для проекта ШЭЛ
Название: Архив Е.В.
Отправлено: Ramil от 22 Октябрь 2006, 05:26:05
Цитировать
Цитировать
Чем критиковать, лучше денег дай ;) . Сколько там надо на такую нормальную работу - 5 месяцев * 5 человек * 1,5 штуки в месяц каждому = 40 штук на новый движок (с гарантией 50%)?
От требований зависит. Но исходя из моего опыта:
3 месяца (max) * 2 человека (max) * как договоришься (вилка думаю от 500 - 1500) = 3000 - 9000 (с вероятностью 90%, если нормально контролировать процесс, а не забить на него и только спрасить результат спустя 3 месяца).
Как говорил мой бывший шеф: Цену проекта очень легко определить. Смотришь сколько стоит автомобиль ген. директора.  Ровно столько стоит система автоматизации его фирмы.
Так, на чем ездит Евгений Витальевич ?
Название: Архив Е.В.
Отправлено: Евгений_Витальевич от 22 Октябрь 2006, 15:37:40
Цитировать
Идеальный вариант нанять фирму, что бы систему управления контентом написали по уму и с документацией.
Probovali i eto. V rezultate polu4ili produkt raz v 10 huje nyneshnego.
Название: Архив Е.В.
Отправлено: Евгений_Витальевич от 22 Октябрь 2006, 15:43:04
Цитировать
Цитировать
Идеальный вариант нанять фирму, что бы систему управления контентом написали по уму и с документацией.
Probovali i eto. V rezultate polu4ili produkt raz v 10 huje nyneshnego.
Tut komandu sdelat' ushe pytalis' - dlja razrabotki tehzadanija. Rezultat=govno.
Napisat' 4to0to rabotajuschee sposoben tolko 1 4elovek. No dokumentacii vse ravno ne dojdeschsja

Vse firmy starajutsja za 10000 prodat' svoi starye razrabotki. Ilja byl edinstvennym za 5 let, kto vse sdelal s nulja po moemu TZ.   Ostal'nye 420 individualnyh razrabot4ikov i firm, s kotorymi ja imel delo za 5 let, okazyvalis' moshennikami ili bezdarjami, ne sposobnymi k 4emu-tu priemlemomu.
Den'gi roli tut ne igrajut.
Название: Архив Е.В.
Отправлено: Евгений_Витальевич от 22 Октябрь 2006, 15:45:09
Цитировать
Так, на чем ездит Евгений Витальевич ?
BMV m3 turbo evclusiv
Название: Архив Е.В.
Отправлено: t_vitali от 22 Октябрь 2006, 23:08:18
Цитировать
Цитировать
Цитировать
Идеальный вариант нанять фирму, что бы систему управления контентом написали по уму и с документацией.
Probovali i eto. V rezultate polu4ili produkt raz v 10 huje nyneshnego.
Tut komandu sdelat' ushe pytalis' - dlja razrabotki tehzadanija. Rezultat=govno.
Napisat' 4to0to rabotajuschee sposoben tolko 1 4elovek. No dokumentacii vse ravno ne dojdeschsja

Vse firmy starajutsja za 10000 prodat' svoi starye razrabotki. Ilja byl edinstvennym za 5 let, kto vse sdelal s nulja po moemu TZ.   Ostal'nye 420 individualnyh razrabot4ikov i firm, s kotorymi ja imel delo za 5 let, okazyvalis' moshennikami ili bezdarjami, ne sposobnymi k 4emu-tu priemlemomu.
Den'gi roli tut ne igrajut.
Я вижу что рынок для консалтинга большой.
Контора на которую я работаю продаёт программы в часности инвест банкам. И пишем группами по 7 - 12 человек. QA отдельная группа. Один человек работу в моём последнем проекте лет за 15 только смог бы сделать. Всё таки за последние 15 лет технология и методология написания программ продвинулась вперёд. Документацию для юзеров пишут специальные люди - у нас целый отдел. Девелоперы пишут техническую документацию, менеджеры собирают юзер реквайрментс, пишут планы, разрабтывают work brakedown structure and ect. Если девелопер не пишет положенные документы то это значит процессы разработки софта не поствлены или их вообще нет. А если он принципиально их не пишет то это значит он или не соотвецтвует заимаемой должности или использует технику secure your workplace и в обоих случаях от него нахер избавляться надо быстрее.
420 фирм - это большая выборка. Как поделился опытом работы с русской компанией мой друг (то же менеджер) - их надо держать на голодном пайке и деньги платить когда уже проект закончен. Можно сказать одно - работать не умеют ни хуя. Сказывается отсуцтвие опыта и толковых менеджеров.
 
Название: Архив Е.В.
Отправлено: t_vitali от 22 Октябрь 2006, 23:16:05
Цитировать
Цитировать
Вообще народ - кто нибудь в скриптах пробовал разбираться? Особенно если скрипты  писал гений одиночка? Млин...
Если код писался не соблюдая стандартов, тем более скрипты, то обычно легче старый код на хер выбросить и новый написать. Это давно известная проблема и она решаема - по пальцам железной линейкой. Для того что бы таких косяков не было - пишут группами, + обязательное ведение документации, + постоянные код ревью и ещё много всякой всячины (такой как планы развития с описанием фичеров, Source Safe - чтобы можно было бы отслеживать изменения, вести версии, тестирование и т.д.). Это уже технология господа - Software Development называется. То есть должны быть организованны процессы в рамках проекта. А когда всё отдаётся на откуп одному человеку, тем более гению, когда он исчезает - проект рушится. ШЭЛ не первый кто на эти грабли наступил.
ШЭЛ сам по себе проект большой. Когда то можно было что то на коленке нацарапать и это работало. Но вот с изменениями и расширением проблемы. Это результат отсуцтвия менеджмента и просто технологии.
Моя мысль такая - не зачем свой не профессионализм и отсутствие опыта списывать на Господа. Он лишь указывает - ШЕЛ проэкт большой и серьёзный. Поэтому требует серьёзного к себе отношения. Господь говорит - измени отношение и сделай шаг вперёд. Перестань ШЭЛ воспринимать легко.
Нужна команда которая будет проект развивать или поддерживать. Нужен менеджер. Идеальный вариант нанять фирму, что бы систему управления контентом написали по уму и с документацией. Потом пусть админ - администрирует, а контора дописывает фичеры.
Чем критиковать, лучше денег дай ;) . Сколько там надо на такую нормальную работу - 5 месяцев * 5 человек * 1,5 штуки в месяц каждому = 40 штук на новый движок (с гарантией 50%)?
Вопрос тут не не в деньгах. Вероятность того что они будут проёбаны = 98%. При чем если индусы делают всё красиво - и документы, и код дукументирован и аботает иногда - то тут получешь на выходе только отмазки.
Процессы должны быть поставлены. Выяснено, чего же заказчик на самом деле хочет, разработанны планы, просчитанно - а сколько это будет стоить? Потом принимается решение - делать или нет. При этом фаза исследования может достигать стоимости до 5% от стоимости проекта.
Название: Архив Е.В.
Отправлено: t_vitali от 22 Октябрь 2006, 23:17:44
Цитировать
Цитировать
Цитировать
Чем критиковать, лучше денег дай ;) . Сколько там надо на такую нормальную работу - 5 месяцев * 5 человек * 1,5 штуки в месяц каждому = 40 штук на новый движок (с гарантией 50%)?
От требований зависит. Но исходя из моего опыта:
3 месяца (max) * 2 человека (max) * как договоришься (вилка думаю от 500 - 1500) = 3000 - 9000 (с вероятностью 90%, если нормально контролировать процесс, а не забить на него и только спрасить результат спустя 3 месяца).
Как говорил мой бывший шеф: Цену проекта очень легко определить. Смотришь сколько стоит автомобиль ген. директора.  Ровно столько стоит система автоматизации его фирмы.
Так, на чем ездит Евгений Витальевич ?
М-да.... Вот Вам и методология. Млин....
Название: Архив Е.В.
Отправлено: Flammar от 23 Октябрь 2006, 08:16:45
Цитировать
Цитировать
Цитировать
Цитировать
Чем критиковать, лучше денег дай ;) . Сколько там надо на такую нормальную работу - 5 месяцев * 5 человек * 1,5 штуки в месяц каждому = 40 штук на новый движок (с гарантией 50%)?
От требований зависит. Но исходя из моего опыта:
3 месяца (max) * 2 человека (max) * как договоришься (вилка думаю от 500 - 1500) = 3000 - 9000 (с вероятностью 90%, если нормально контролировать процесс, а не забить на него и только спрасить результат спустя 3 месяца).
Как говорил мой бывший шеф: Цену проекта очень легко определить. Смотришь сколько стоит автомобиль ген. директора.  Ровно столько стоит система автоматизации его фирмы.
Так, на чем ездит Евгений Витальевич ?
М-да.... Вот Вам и методология. Млин....
Это стоимость системы автоматизации бардака ;) Который по определению невозможно автоматизировать.
Название: Архив Е.В.
Отправлено: Flammar от 23 Октябрь 2006, 10:35:32
Цитировать
Цитировать
Цитировать
Цитировать
Идеальный вариант нанять фирму, что бы систему управления контентом написали по уму и с документацией.
Probovali i eto. V rezultate polu4ili produkt raz v 10 huje nyneshnego.
Tut komandu sdelat' ushe pytalis' - dlja razrabotki tehzadanija. Rezultat=govno.
Napisat' 4to0to rabotajuschee sposoben tolko 1 4elovek. No dokumentacii vse ravno ne dojdeschsja

Vse firmy starajutsja za 10000 prodat' svoi starye razrabotki. Ilja byl edinstvennym za 5 let, kto vse sdelal s nulja po moemu TZ.   Ostal'nye 420 individualnyh razrabot4ikov i firm, s kotorymi ja imel delo za 5 let, okazyvalis' moshennikami ili bezdarjami, ne sposobnymi k 4emu-tu priemlemomu.
Den'gi roli tut ne igrajut.
Я вижу что рынок для консалтинга большой.
Контора на которую я работаю продаёт программы в часности инвест банкам. И пишем группами по 7 - 12 человек. QA отдельная группа. Один человек работу в моём последнем проекте лет за 15 только смог бы сделать. Всё таки за последние 15 лет технология и методология написания программ продвинулась вперёд. Документацию для юзеров пишут специальные люди - у нас целый отдел. Девелоперы пишут техническую документацию, менеджеры собирают юзер реквайрментс, пишут планы, разрабтывают work brakedown structure and ect. Если девелопер не пишет положенные документы то это значит процессы разработки софта не поствлены или их вообще нет. А если он принципиально их не пишет то это значит он или не соотвецтвует заимаемой должности или использует технику secure your workplace и в обоих случаях от него нахер избавляться надо быстрее.
420 фирм - это большая выборка. Как поделился опытом работы с русской компанией мой друг (то же менеджер) - их надо держать на голодном пайке и деньги платить когда уже проект закончен. Можно сказать одно - работать не умеют ни хуя. Сказывается отсуцтвие опыта и толковых менеджеров.
Эффективно можно заниматься одним из двух - либо писать код либо блюсти стандарты. Из тех, кто эффективно блюдет стандарты, можно, как из деталей, собирать некий голем. Из тех, кто эффективно пишет - намного труднее. Я еще где-то в 1997 заметил, что написание документации на программу - дело более трудоемкое, чем написание самой программы.

Продукция голема, собранного из тех, кто эффективно блюдет стандарты, может быть, и менее эффективна, чем продукция одиночки гения, но более поддержабельна, более документирована, ее легче передать в работу незнакомому программисту. Другое дело, не всегда понятно, зачем это надо - нужда в этом может отпасть раньше, чем это будет сделано.
Название: Архив Е.В.
Отправлено: Колобок от 23 Октябрь 2006, 11:34:24
Цитировать
Эффективно можно заниматься одним из двух - либо писать код либо блюсти стандарты. Из тех, кто эффективно блюдет стандарты, можно, как из деталей, собирать некий голем. Из тех, кто эффективно пишет - намного труднее. Я еще где-то в 1997 заметил, что написание документации на программу - дело более трудоемкое, чем написание самой программы.
Одно дело стандарты, другое дело читабельность кода. Стандарты во всех фирмах разные. А легко читаемый код можно писать и без стандартов. Пожалуй, это одна из основных характеристик хорошего программиста, по моему мнению. Как говорит знакомый руководитель проектов, хорошая программа сама по себе и является документацией.
Название: Архив Е.В.
Отправлено: grigory от 23 Октябрь 2006, 12:49:33
Цитата: Евгений_Витальевич,22.10.2006 13:43
Цитата: Евгений_Витальевич,22.10.2006 13:37
Цитата: t_vitali,20.10.2006 04:27
Идеальный вариант нанять фирму, что бы систему управления контентом написали по уму и с документацией.
Probovali i eto. V rezultate polu4ili produkt raz v 10 huje nyneshnego.
Tut komandu sdelat' ushe pytalis' - dlja razrabotki tehzadanija. Rezultat=govno.
[/QUOTE]


Евгений Витальевич!

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

Думаю, что многие выпускники ШЭЛ, да и члены этого форума, готовы оказать помощь Проекту в поиске достойных программистов.
Название: Архив Е.В.
Отправлено: t_vitali от 23 Октябрь 2006, 18:48:31
Цитировать
Цитировать
Цитировать
Цитировать
Цитировать
Идеальный вариант нанять фирму, что бы систему управления контентом написали по уму и с документацией.
Probovali i eto. V rezultate polu4ili produkt raz v 10 huje nyneshnego.
Tut komandu sdelat' ushe pytalis' - dlja razrabotki tehzadanija. Rezultat=govno.
Napisat' 4to0to rabotajuschee sposoben tolko 1 4elovek. No dokumentacii vse ravno ne dojdeschsja

Vse firmy starajutsja za 10000 prodat' svoi starye razrabotki. Ilja byl edinstvennym za 5 let, kto vse sdelal s nulja po moemu TZ.   Ostal'nye 420 individualnyh razrabot4ikov i firm, s kotorymi ja imel delo za 5 let, okazyvalis' moshennikami ili bezdarjami, ne sposobnymi k 4emu-tu priemlemomu.
Den'gi roli tut ne igrajut.
Я вижу что рынок для консалтинга большой.
Контора на которую я работаю продаёт программы в часности инвест банкам. И пишем группами по 7 - 12 человек. QA отдельная группа. Один человек работу в моём последнем проекте лет за 15 только смог бы сделать. Всё таки за последние 15 лет технология и методология написания программ продвинулась вперёд. Документацию для юзеров пишут специальные люди - у нас целый отдел. Девелоперы пишут техническую документацию, менеджеры собирают юзер реквайрментс, пишут планы, разрабтывают work brakedown structure and ect. Если девелопер не пишет положенные документы то это значит процессы разработки софта не поствлены или их вообще нет. А если он принципиально их не пишет то это значит он или не соотвецтвует заимаемой должности или использует технику secure your workplace и в обоих случаях от него нахер избавляться надо быстрее.
420 фирм - это большая выборка. Как поделился опытом работы с русской компанией мой друг (то же менеджер) - их надо держать на голодном пайке и деньги платить когда уже проект закончен. Можно сказать одно - работать не умеют ни хуя. Сказывается отсуцтвие опыта и толковых менеджеров.
Эффективно можно заниматься одним из двух - либо писать код либо блюсти стандарты. Из тех, кто эффективно блюдет стандарты, можно, как из деталей, собирать некий голем. Из тех, кто эффективно пишет - намного труднее. Я еще где-то в 1997 заметил, что написание документации на программу - дело более трудоемкое, чем написание самой программы.

Продукция голема, собранного из тех, кто эффективно блюдет стандарты, может быть, и менее эффективна, чем продукция одиночки гения, но более поддержабельна, более документирована, ее легче передать в работу незнакомому программисту. Другое дело, не всегда понятно, зачем это надо - нужда в этом может отпасть раньше, чем это будет сделано.
Со всем уважением - это немного устаревшие представления. Вся современная технология написания програм как раз и избегает создания голема. Группы собираются из 6 - максимум 12 человек (если 12 человек то уже работаю с групп лидерами). Вот для этого и нужен менеджер. Видимо тут присуцтвует понимание стандарта как на конвейре - отступ 2 миллиметра и не более. При понимании стандартов как некоторых правил которые облегчают работу всех в группе ( и в компании )  на выходе имеем совершенно другое. К стати и стандарты группа принимает в начале проекта сама. Если что то не устраивает то либо стандарт меняется, либо если, что то что зависит от компании целиком - Source Safe, или Rationl Rose Uninfied Process используется к примеру то курсы организуются и т.д.
Конечно писать документы очень тяжело. Документы для юзеров ишут не девелоперы, а переводчики с технического на нормальный язык Technical Writers. Но документы необходимые в проессе разработки (Functional Requirement Specification, High level design description, Class Diagramm) пишутся девелоперами. Это уже часть квалификации - без этого это не  девелопер - это код манки. На работу не возьмут.

Проблема одиночки гения vs работы группы. Во первых компании которые превращают деелопмент групы в големы блюдущие стандарты долго не живут - не конвейер. Но всё же современный Software Development - это результат работы группы. Посмотри на это немного с другой стороны. Сравни - сколько может написать один гений и сколько может написать группа из 5 - 10 человек? Несравнимо. Гений будет писать 2 года  то что группа сделает за 6 месяцев. А полтора года на рынке это очень много. Потом - написание программы это только часть процесса. Потом её надо передать клиенту, фиксить баги, вносить изменения - у клиента ведь обстоятельства и желния меняются. Как это делать? Ведь нормальному человеку хочется новое писать, а не ковыряться с багами, или менять то что написанно. А гений уйдёт просто с работы. А если он башку кому нибудь проломит? Всё? Фирма влетела и разорилась? Риски то просчитываются. Вот посмотри на ситуацию - пропал разработчик и всё - проект встал в развитии.
Я стобой согласен - гений и работает быстрее и эффективней и код красивее. Но вот заболел он и проек слился в говно. А если работать с клиентами с которыми моя теперешняя контора работает то и вся фирма. Подымись на одну ступень выше. Посмотри на процесс с точки зрения проекта.
Тут интересно сравнить мой опыт работы в Израиле и в Канаде. В Израиле программеры на две головы в среднем выше чем в Канаде. Таких групп лидеров которе были у меня таких тут просто нет. Золоте головы. А менеджмент намного слабее. В Канаде наоборот - программеры слабые, а менеджмент очень сильный. В реультате делают в два раза больше и качественней. Только за счет организации. И работают только положенные 9 часов. В Израиле были сплошные овертаймы.
Название: Архив Е.В.
Отправлено: t_vitali от 23 Октябрь 2006, 19:07:38
Цитировать
Цитировать
Эффективно можно заниматься одним из двух - либо писать код либо блюсти стандарты. Из тех, кто эффективно блюдет стандарты, можно, как из деталей, собирать некий голем. Из тех, кто эффективно пишет - намного труднее. Я еще где-то в 1997 заметил, что написание документации на программу - дело более трудоемкое, чем написание самой программы.
Одно дело стандарты, другое дело читабельность кода. Стандарты во всех фирмах разные. А легко читаемый код можно писать и без стандартов. Пожалуй, это одна из основных характеристик хорошего программиста, по моему мнению. Как говорит знакомый руководитель проектов, хорошая программа сама по себе и является документацией.
Читабельность кода - это часть стандарта, да и просто правило хорошего тона. Второе утверждение - о хорошей программе - довольно распостранённое заблуждение. Тех кто может это действительно сделать по пальцам пересчитать - остльные только считают, что они крутые.
Хорошая организация процесса позволяет с посредственными программерами делать больше и лучше, позволяет скомпенсироватьих недостатки. Что в общем и делают на западе в общем. Посмотришь - ну бараны вокруг работают, а идут в одном направлении, стены проламывают, результатов добиваются блестящх и при этом не сильно напрягаются.  
Название: Архив Е.В.
Отправлено: НикНик от 23 Октябрь 2006, 20:27:10
Для начала предлагаю обрисовать пожелания к задаче, чтоб из него можно было тз состряпать. ТЗ состовляет разработчик (или хотя бы посредник). Короче, предлагаю объявить тендор. Выкладывайте ТЗ и задавайте вопросы.
Название: Архив Е.В.
Отправлено: Ramil от 25 Октябрь 2006, 09:07:33
Цитировать
Цитата: Ramil,22.10.2006 03:26
Цитата: AlexD,20.10.2006 11:37
Так, на чем ездит Евгений Витальевич ?
М-да.... Вот Вам и методология. Млин....
Чувствуется наболело...
Шуточная - это методология. Абсолютно адекватная в РФ  :lol:
Зато я цену назвал. От 50 до 120 тыс уев.
Редкому клиенту интересно смотреть на картинки UML.
 
Название: Архив Е.В.
Отправлено: t_vitali от 25 Октябрь 2006, 18:45:58
Цитировать
Цитата: t_vitali,22.10.2006 21:17
Цитата: Ramil,22.10.2006 03:26
Цитата: AlexD,20.10.2006 11:37
Так, на чем ездит Евгений Витальевич ?
М-да.... Вот Вам и методология. Млин....
Чувствуется наболело...
Шуточная - это методология. Абсолютно адекватная в РФ  :lol:
Зато я цену назвал. От 50 до 120 тыс уев.
Редкому клиенту интересно смотреть на картинки UML.
Знаешь скорее вызывает удивление. Представления конца прошлого века... Методология тоже :) Контраст - программеры росиийские одни из лучших в мире - а менеджмент....
Понятие клиента оно диференцированно. Нет такого монолитного клиента. Есть люди принимающие решение покупать родукт или нет. UML конечно этой части клиент никто не показывает. Ему показывают roadmap - то есть куда продукт развивается и как у клиента он интегрируется. И разговор идёт в форме - вы платите столько то, экономите (зарабатываете) столькото. Эти товарищи опираются на мнение технических специалистов - с ними разговор идёт в других терминах. Как тяжело устанавливать продукт, какое удобсво он даёт, каково качество тех. документации, есть ли hot line для решения проблем, план итеграции, план на случай катастрофы и т.д.
Сейчас в мире клиент является активным участником разработки продукта. То есть успех клиента является частью моего успеха. Он вовлекается максимальным образом в процесс. У меня встречи с каждым  клиентом раз в две недели запланированны. Обсуждения идут - какие проблемы были, что нужно в следующей версии и т.д. В общем осущестление Project Communication Management. И соотвецтенно корекция планов для следующей версии, фиксы наиболее критических багов и т.д.
 
Название: Архив Е.В.
Отправлено: eugeni_bs от 26 Октябрь 2006, 23:43:29
Евгений Витальевич, раз создание новых движков сорвалось и переносится, то и выкладывание новых материалов тоже сорвалось?
Название: Архив Е.В.
Отправлено: avl от 27 Октябрь 2006, 11:46:09
Цитировать
Контраст - программеры росиийские одни из лучших в мире - а менеджмент....
Легко собрать стадо из баранов, но трудно - из кошек. У хороших программеров есть четкие собственные представления о том, как правильно писать программы и договориться им часто бывает непросто.
Название: Архив Е.В.
Отправлено: t_vitali от 27 Октябрь 2006, 20:49:00
Цитировать
Цитировать
Контраст - программеры росиийские одни из лучших в мире - а менеджмент....
Легко собрать стадо из баранов, но трудно - из кошек. У хороших программеров есть четкие собственные представления о том, как правильно писать программы и договориться им часто бывает непросто.
Конечно не просто. Поэтому в первых есть некоторые стандарты внутри компании, во вторых есть менеджер задача которого этот процесс запустить и поддерживать.

Договоряться - нужно только процессом управлять. Это и есть работа менеджера.
Название: Архив Е.В.
Отправлено: avl от 29 Октябрь 2006, 10:14:40
Цитировать
Конечно не просто. Поэтому в первых есть некоторые стандарты внутри компании, во вторых есть менеджер задача которого этот процесс запустить и поддерживать.

Договоряться - нужно только процессом управлять. Это и есть работа менеджера.
Я не встречал ни разу менеджера который мог бы этим процессом управлять, по крайней мере, явно. Возможно, они могли управлять этим процессом среди американских или китайских программеров.
Но на русских программеров влияние менеджеров какое-то вялое, ибо хороший програмер (в данном случае важно что он хороший, а не то что он русский) обладает значительным авторитетом среди коллег. Поэтому все определяется в основном бессознательно складывающейся ситуаций в группе - кто-то с кем-то посрался, кто-то подружился. Управлять этим процессом может только человек, который специально этому обучался, кои встречаются среди менеджеров редко.
Причем, даже если менеджеру объяснить ситуацию, это не помогает, он просто не воспринимает ее в таком разрезе.
Название: Архив Е.В.
Отправлено: Евгений_Витальевич от 29 Октябрь 2006, 17:04:50
Цитировать
Думаю, что многие выпускники ШЭЛ, да и члены этого форума, готовы оказать помощь Проекту в поиске достойных программистов.
Ushe 5 let okazyvajut  :lol:  
Название: Архив Е.В.
Отправлено: Flammar от 31 Октябрь 2006, 12:58:00
Про фирмы и ЕВ's портал.

Фирмы заточены под традиционные задачи и тардиционных клиентов. ЕВ оказался для них нетрадиционным клиентом с нетрадиционными задачами. И просто ЕВ оказался не их клиентом.
Название: Архив Е.В.
Отправлено: Aelita от 31 Октябрь 2006, 15:21:51
Цитировать
Про фирмы и ЕВ's портал.

Фирмы заточены под традиционные задачи и тардиционных клиентов. ЕВ оказался для них нетрадиционным клиентом с нетрадиционными задачами. И просто ЕВ оказался не их клиентом.
Функциональность имеющегося сайта не включает никаких "нетрадиционных задач".
Не имея ТЗ, трудно сказать, что там могло быть "нетрадиционного". И в чём вообще могла возникнуть проблема.
Название: Архив Е.В.
Отправлено: t_vitali от 31 Октябрь 2006, 18:43:34
Цитировать
Цитировать
Конечно не просто. Поэтому в первых есть некоторые стандарты внутри компании, во вторых есть менеджер задача которого этот процесс запустить и поддерживать.

Договоряться - нужно только процессом управлять. Это и есть работа менеджера.
Я не встречал ни разу менеджера который мог бы этим процессом управлять, по крайней мере, явно. Возможно, они могли управлять этим процессом среди американских или китайских программеров.
Но на русских программеров влияние менеджеров какое-то вялое, ибо хороший програмер (в данном случае важно что он хороший, а не то что он русский) обладает значительным авторитетом среди коллег. Поэтому все определяется в основном бессознательно складывающейся ситуаций в группе - кто-то с кем-то посрался, кто-то подружился. Управлять этим процессом может только человек, который специально этому обучался, кои встречаются среди менеджеров редко.
Причем, даже если менеджеру объяснить ситуацию, это не помогает, он просто не воспринимает ее в таком разрезе.
Сдесь видимо идёт путаница понятий - управлять процессом, влиять на программеров, управлять группой. Это разные вещи. Давай с начала.
На современном этапе задача и назначение менеджера - это "создание условий для успеха группы (успешного достижения поставленных целей)". Не больше и не меньше. То есть - согласовать вопросы со стейк холдерами, определить цель проекта, получить бюджет, распланировать работу (с участием группы), обеспечить софтом и всем необходимым, определить процессы написания кода, код ревью, процессы контроля качества, процессы доставки и интеграции продукта у клиента, процессы комуникации со стейк холдерами, составить реестр рисков (риск менеджмент план), план на случай катастрофы. Есть ещё пункты долго получиться перечислять. Производственные процессы которые будут идти в группе закладываются на этапе планирования и с участием группы.
Хочу отметить принципиальную разницу в подходе к менджмету (в Software Industry) - сейчас на группу смотрят как на источник всех идей и главную ценность компании. То есть менеджер не управляет группой - т.е. раздаёт указания что, как и в какие сроки надо делать. Не подгоняет - давай, давай, быстрей, быстрей. Он только создаёт условия, ограждает от политики, создаёт каналы общения со стейк холдерами - помогает. Тут очень тонкая грань. Через 3 года менеджер теряет квалификацию как программер. Его задача создавать условия - организовывать.
С влиянием на русских програмистов обычно проблем не возникает - нужно только показать, что ты то же борешься за торжество Object Oriented в мире :)
Название: Архив Е.В.
Отправлено: mode от 01 Ноябрь 2006, 08:43:26
Цитировать
Цитировать
Цитировать
Конечно не просто. Поэтому в первых есть некоторые стандарты внутри компании, во вторых есть менеджер задача которого этот процесс запустить и поддерживать.

Договоряться - нужно только процессом управлять. Это и есть работа менеджера.
Я не встречал ни разу менеджера который мог бы этим процессом управлять, по крайней мере, явно. Возможно, они могли управлять этим процессом среди американских или китайских программеров.
Но на русских программеров влияние менеджеров какое-то вялое, ибо хороший програмер (в данном случае важно что он хороший, а не то что он русский) обладает значительным авторитетом среди коллег. Поэтому все определяется в основном бессознательно складывающейся ситуаций в группе - кто-то с кем-то посрался, кто-то подружился. Управлять этим процессом может только человек, который специально этому обучался, кои встречаются среди менеджеров редко.
Причем, даже если менеджеру объяснить ситуацию, это не помогает, он просто не воспринимает ее в таком разрезе.
Сдесь видимо идёт путаница понятий - управлять процессом, влиять на программеров, управлять группой. Это разные вещи. Давай с начала.
На современном этапе задача и назначение менеджера - это "создание условий для успеха группы (успешного достижения поставленных целей)". Не больше и не меньше. То есть - согласовать вопросы со стейк холдерами, определить цель проекта, получить бюджет, распланировать работу (с участием группы), обеспечить софтом и всем необходимым, определить процессы написания кода, код ревью, процессы контроля качества, процессы доставки и интеграции продукта у клиента, процессы комуникации со стейк холдерами, составить реестр рисков (риск менеджмент план), план на случай катастрофы. Есть ещё пункты долго получиться перечислять. Производственные процессы которые будут идти в группе закладываются на этапе планирования и с участием группы.
Хочу отметить принципиальную разницу в подходе к менджмету (в Software Industry) - сейчас на группу смотрят как на источник всех идей и главную ценность компании. То есть менеджер не управляет группой - т.е. раздаёт указания что, как и в какие сроки надо делать. Не подгоняет - давай, давай, быстрей, быстрей. Он только создаёт условия, ограждает от политики, создаёт каналы общения со стейк холдерами - помогает. Тут очень тонкая грань. Через 3 года менеджер теряет квалификацию как программер. Его задача создавать условия - организовывать.
С влиянием на русских програмистов обычно проблем не возникает - нужно только показать, что ты то же борешься за торжество Object Oriented в мире :)
т.е. менеджер выступает как продюсер и режиссер, а программерская комманда - как команда актеров на площадке. Задача продюсера - создание институциональной среды, которая позволяет труппе максимально проявить свои таланты и при этом уложиться в сметы - сделать проект прибыльным. задача режиссера - авторская обработка заказа и трансляция его труппе.

Я правильно понимаю?
Название: Архив Е.В.
Отправлено: den от 01 Ноябрь 2006, 09:31:09
Цитировать
Цитировать
Цитировать
Конечно не просто. Поэтому в первых есть некоторые стандарты внутри компании, во вторых есть менеджер задача которого этот процесс запустить и поддерживать.

Договоряться - нужно только процессом управлять. Это и есть работа менеджера.
Я не встречал ни разу менеджера который мог бы этим процессом управлять, по крайней мере, явно. Возможно, они могли управлять этим процессом среди американских или китайских программеров.
Но на русских программеров влияние менеджеров какое-то вялое, ибо хороший програмер (в данном случае важно что он хороший, а не то что он русский) обладает значительным авторитетом среди коллег. Поэтому все определяется в основном бессознательно складывающейся ситуаций в группе - кто-то с кем-то посрался, кто-то подружился. Управлять этим процессом может только человек, который специально этому обучался, кои встречаются среди менеджеров редко.
Причем, даже если менеджеру объяснить ситуацию, это не помогает, он просто не воспринимает ее в таком разрезе.
Сдесь видимо идёт путаница понятий - управлять процессом, влиять на программеров, управлять группой. Это разные вещи. Давай с начала.
На современном этапе задача и назначение менеджера - это "создание условий для успеха группы (успешного достижения поставленных целей)". Не больше и не меньше. То есть - согласовать вопросы со стейк холдерами, определить цель проекта, получить бюджет, распланировать работу (с участием группы), обеспечить софтом и всем необходимым, определить процессы написания кода, код ревью, процессы контроля качества, процессы доставки и интеграции продукта у клиента, процессы комуникации со стейк холдерами, составить реестр рисков (риск менеджмент план), план на случай катастрофы. Есть ещё пункты долго получиться перечислять. Производственные процессы которые будут идти в группе закладываются на этапе планирования и с участием группы.
Хочу отметить принципиальную разницу в подходе к менджмету (в Software Industry) - сейчас на группу смотрят как на источник всех идей и главную ценность компании. То есть менеджер не управляет группой - т.е. раздаёт указания что, как и в какие сроки надо делать. Не подгоняет - давай, давай, быстрей, быстрей. Он только создаёт условия, ограждает от политики, создаёт каналы общения со стейк холдерами - помогает. Тут очень тонкая грань. Через 3 года менеджер теряет квалификацию как программер. Его задача создавать условия - организовывать.
С влиянием на русских програмистов обычно проблем не возникает - нужно только показать, что ты то же борешься за торжество Object Oriented в мире :)
Грамотно и по делу.
Название: Архив Е.В.
Отправлено: eugeni_bs от 11 Июнь 2007, 18:15:33
Дык еще в сентябре прошлого года планировалось открыть персональный (зачем?) сайт Гильбо, где выкладывались бы архивы ЕВ. Какой смысл прятать эти архивы?

Цитировать

Цитировать
Цитировать
Цитировать
Я к тому, что можно ведь просто сделать ev.gilbo.ru и там статьи выкладывать так же как и здесь: http://analysisclub.ru/index.php?page=econom1995 (http://analysisclub.ru/index.php?page=econom1995) - никаких новых особых движков не нужно.

 
К сожалению, этот движок неклонируем. Сделали новый.
Когда планируете запускать свой сайт, Е.В.?
В сентябре
Название: Архив Е.В.
Отправлено: Евгений_Витальевич от 11 Июнь 2007, 20:39:37
Цитировать
Дык еще в сентябре прошлого года планировалось открыть персональный (зачем?) сайт Гильбо, где выкладывались бы архивы ЕВ. Какой смысл прятать эти архивы?
 
А это вопрос к Господу Богу. Высокая текучесть кадров. как только очередной программист подходит к реализации этого проекта, его то инсульт схватит, то посадят, то с ума сойдет...  А если нет ветра в паруса, преодолевать трудности по-советски-героически я не стану. С Господом Богом не воюю.
Название: Архив Е.В.
Отправлено: eugeni_bs от 12 Июнь 2007, 10:30:00
Цитировать
Цитировать
Дык еще в сентябре прошлого года планировалось открыть персональный (зачем?) сайт Гильбо, где выкладывались бы архивы ЕВ. Какой смысл прятать эти архивы?
 
А это вопрос к Господу Богу. Высокая текучесть кадров. как только очередной программист подходит к реализации этого проекта, его то инсульт схватит, то посадят, то с ума сойдет...  А если нет ветра в паруса, преодолевать трудности по-советски-героически я не стану. С Господом Богом не воюю.
Дык вы бы программерам платили - они бы и делали...
Название: Архив Е.В.
Отправлено: vlyerm от 12 Июнь 2007, 14:31:23
Если Господь - это Абсолютная Идея, то как может идея иметь субъектность и собственную волю для реализации своих планов, поддерживая одни процессы и тормозя другие?
Название: Архив Е.В.
Отправлено: yiri_a от 12 Июнь 2007, 14:55:36
Господь Бог- абсолютная идея. И в созданные им законы действия этого мира
открытие персонального сайта Гилбо невписывается .
 Сайт оказался неформатным. :lol:  
Название: Архив Е.В.
Отправлено: Евгений_Витальевич от 12 Июнь 2007, 21:12:45
Цитировать
Цитировать
Цитировать
Дык еще в сентябре прошлого года планировалось открыть персональный (зачем?) сайт Гильбо, где выкладывались бы архивы ЕВ. Какой смысл прятать эти архивы?
 
А это вопрос к Господу Богу. Высокая текучесть кадров. как только очередной программист подходит к реализации этого проекта, его то инсульт схватит, то посадят, то с ума сойдет...  А если нет ветра в паруса, преодолевать трудности по-советски-героически я не стану. С Господом Богом не воюю.
Дык вы бы программерам платили - они бы и делали...
платил. Не делают.
Если бы дело было только в деньгах, проблем бы не было
Название: Архив Е.В.
Отправлено: Father от 13 Июнь 2007, 07:57:18
Цитировать
Дык вы бы программерам платили - они бы и делали...
платил. Не делают.
Если бы дело было только в деньгах, проблем бы не было [/quote]
 Дык может конкуренты им больше платят и они сабатируют? :lol:  
Название: Архив Е.В.
Отправлено: Merebel от 01 Октябрь 2007, 21:46:22
Интересно, от чего это программисты инфаркты получают и с ума сходят. :)
А можно как-то в проектах поучавствовать?
Название: Re: Архив Е.В.
Отправлено: MaxBlack от 24 Ноябрь 2011, 11:10:26
Цитировать
Дык еще в сентябре прошлого года планировалось открыть персональный (зачем?) сайт Гильбо, где выкладывались бы архивы ЕВ. Какой смысл прятать эти архивы?
 
А это вопрос к Господу Богу. Высокая текучесть кадров. как только очередной программист подходит к реализации этого проекта, его то инсульт схватит, то посадят, то с ума сойдет...  А если нет ветра в паруса, преодолевать трудности по-советски-героически я не стану. С Господом Богом не воюю.

А может это Надсмотрщик мешает :g: :lol:
Вы же сами в рассылке писали что интуиция говорит что надо делать, а Надсмотрщик что не надо