Ну за все крупные компании расписываться не могу, мы в нашей компанни работали с двумя крупными американскими компаниями. Обе весьма успешны. Одна из них требовала от нас введения CMM-а, хотя сама при этом внедряла его весьма небрежно, для галочки.
Во второй компании вообще, как я понял, практически нет 'процесса', ну за исключением абсалютно необходимых вещей типа: контроля версий, баг треккинга и отчетов.
Да и в майкрософте и гугле, насколько я читал, применяется что-то свое. Я так понял там работают небольшими группами, которыми проще управлять.
Мой пойнт в том, что связь между успехом компании и процессом не вполне очевидна.
По поводу 30% — цифра, как я написал, основанна на субъективных наблюдениях. Следование процессу тоже занимает много времени. Например если мы вводим классификацию ошибок, каждый разработчик, или тестеровщик должен сидеть и в отчете аккуратно классифицировать каждый баг. А это может быть настоящим pain in the ass.
Главное при разработке процесса на каждом шаге спрашивать себя, а каковы конечные цели? Если цель — преодоление хаоса, то это один случай, здесь можно обойтись более простыми вещами и CMM, и пр. здесь избыточны.
Если цель дать менеджерам возможность понимания что происходит на всех проектах — это другое. Если нужно чтобы руководство компаннии могло влиять на процесс в целом по компании — это третье.
Т.е. на каждом шаге важна целесообразность — не за чем собирать по компании метрики если руководство не собирается на них смотреть.
А вообще, такой вопрос: вы в своей компании на самом деле собрались внедрять CMMi или это был просто теоретический обзор?
Сколько же рабочего времени мы убили в нашей компании на эту муть.
Imho, СММ(i) пригодна когда заказчик хочет видет 'внутренности' процесса разработки, который делает подрядчик.
В остальном же это — мифилогизированный фетиш для больших компаний которым некуда выкинуть деньги.
Нигде не встречал сколько-нибудь убедительных доказательств что CMM и подобные бюрократизмы повышает эффективность разработки и компании в целом.
А накладные расходы на создание и поддержание процесса могут занимать до 30% рабочего времени (по моим очень субъективным оценкам).
Сорри за эту ложку дёгтя.
Сказанное, разумеется, только мое личное imho.
www.thenakedscientists.com/ — отличный научно-популярный подкаст с транскриптами.
Очень интересный контент.
Слушаю больше года.
уровень языка — advanced.
Очень важно чтобы информация, которую читаешь или слушаешь на изучаемом языке была интересна.
Например, есть замечательный подкаст thenakedscientists.com. Настоятельно рекомендую. Помимо собственно языка узнаешь много нового из мира науки. Или вот еще: skeptoid.com (уровень сложности пониже)
чувак ты явно неадекватен. Не можешь нормально аргументировать свою позицию и начинаешь размазывание соплей "я попадал, ты не попадал, мои проблемы твои проблемы"
мда... и откуда такие дятлы беруться...
удачи..
мда... поток сознания...
Вообщем резюме:
Сроки гарантийного ремонта должны быть прописаны в договоре, заключаемом с сервисным центром, эта длительность не может превышать 5 дней. Если договора нет, то действует статья 20 пункт 2 закона о ЗПП. Т.е. устанавливается срок минимальный срок, "..объективно необходимый для их устранения .." А это понятие сервисные центры могут трактовать весьма гибко.
Вот и все. Возражения есть ?
А что входит в твои обязаности ? вводить людей в заблуждение ?
Если бы ты знал закон, и вопрос был так прост то в чем проблема привести номер статьи ?
Люди, столкнувшиеся с подобной ситуацией ждут нормальных, конструктивных и обоснованных рекомендаций. А не надувания щек и тупых советов сходить к юристу...
Да, это было бы желательно. Поскольку Ваше утверждение про сроки не подтверждается законом, насколько я могу судить.
есть статья 27 в которой сказано что сроки могут быть установлены.
есть статья 18 устанавливающая 5ти дневный срок устранения недостатков.
никакого упоминания про 30 дневный гарантийный ремонт в законе нет..
однако, собственно в самом законе такого нет...
http://www.potrebitel.net/zakon/texts/zozpp/index.html
либо я плохо смотрю либо журналист слегка приврал...
Те же вежливые американцы могут надавать пенделей так, что мама не горюй.
Один из них высказал мысль, которую я стал понимать лишь спустя некоторое время:
Если резульат вашей работы плох - это обязательно заметят, но если результат вашей работы -хорош не ждите что вас похвалят.
По поводу применения "новых техник и финтов" - это все интересно пока есть время. Когда висит жесткий дед-лайн остается одно - фигачить...
Согласен. Критика в отношении фактов содержащихся в статье не является критикой в отношении самой статьи. То что мы пытаемся применить факты которые в ней содержаться к своей ситуации, лишний раз показывает нужность статьи.
Статья в целом понравилось.
но смущают завышенные и, по-моему, противоречивые требования инвесторов:
1) Каримов ищет проекты, которые носят глобальный характер - то есть те, продукция или услуги которых будут востребованы в разных странах и на больших по объему рынках.
2) Это должно быть запатентованное техническое решение.
Всвязи с этим возникают замечания:
- Получается что стартаперы должны получить патент американский или европейский патент. По-моему российские патенты не являются юридическим документов в международных судах (хотя могу ошибаться). А это сопряженно вообщем-то с некоторыми сложностями...
- Если попытаться представить себе ПРОДУКТ который создан небольшим стартапом и при этом продается во всем мире, то на ум приходят только небольшие програмки которые можно скачивать на сайтах типа download.com.
В остальных же случаях, чтобы продавать продукт по-всему миру, нужно быть не маленьким стартапом, а большой компанией с мощными маркетинговыми ресурсами. (Буду рад если меня переубедят и приведут примеры).
В штатах распространена концепция когда небольшие старт-апы разрабоатывают не продукт, а идею, некое частное техническое решение, которое затем может быть продано большими компаниям и использована в их продуктах. Но у нас, понятное дело, пока, такое невозможно.
Во второй компании вообще, как я понял, практически нет 'процесса', ну за исключением абсалютно необходимых вещей типа: контроля версий, баг треккинга и отчетов.
Да и в майкрософте и гугле, насколько я читал, применяется что-то свое. Я так понял там работают небольшими группами, которыми проще управлять.
Мой пойнт в том, что связь между успехом компании и процессом не вполне очевидна.
По поводу 30% — цифра, как я написал, основанна на субъективных наблюдениях. Следование процессу тоже занимает много времени. Например если мы вводим классификацию ошибок, каждый разработчик, или тестеровщик должен сидеть и в отчете аккуратно классифицировать каждый баг. А это может быть настоящим pain in the ass.
Главное при разработке процесса на каждом шаге спрашивать себя, а каковы конечные цели? Если цель — преодоление хаоса, то это один случай, здесь можно обойтись более простыми вещами и CMM, и пр. здесь избыточны.
Если цель дать менеджерам возможность понимания что происходит на всех проектах — это другое. Если нужно чтобы руководство компаннии могло влиять на процесс в целом по компании — это третье.
Т.е. на каждом шаге важна целесообразность — не за чем собирать по компании метрики если руководство не собирается на них смотреть.
А вообще, такой вопрос: вы в своей компании на самом деле собрались внедрять CMMi или это был просто теоретический обзор?
Imho, СММ(i) пригодна когда заказчик хочет видет 'внутренности' процесса разработки, который делает подрядчик.
В остальном же это — мифилогизированный фетиш для больших компаний которым некуда выкинуть деньги.
Нигде не встречал сколько-нибудь убедительных доказательств что CMM и подобные бюрократизмы повышает эффективность разработки и компании в целом.
А накладные расходы на создание и поддержание процесса могут занимать до 30% рабочего времени (по моим очень субъективным оценкам).
Сорри за эту ложку дёгтя.
Сказанное, разумеется, только мое личное imho.
Очень интересный контент.
Слушаю больше года.
уровень языка — advanced.
Например, есть замечательный подкаст thenakedscientists.com. Настоятельно рекомендую. Помимо собственно языка узнаешь много нового из мира науки. Или вот еще: skeptoid.com (уровень сложности пониже)
мда... и откуда такие дятлы беруться...
удачи..
Вообщем резюме:
Сроки гарантийного ремонта должны быть прописаны в договоре, заключаемом с сервисным центром, эта длительность не может превышать 5 дней. Если договора нет, то действует статья 20 пункт 2 закона о ЗПП. Т.е. устанавливается срок минимальный срок, "..объективно необходимый для их устранения .." А это понятие сервисные центры могут трактовать весьма гибко.
Вот и все. Возражения есть ?
Если бы ты знал закон, и вопрос был так прост то в чем проблема привести номер статьи ?
Люди, столкнувшиеся с подобной ситуацией ждут нормальных, конструктивных и обоснованных рекомендаций. А не надувания щек и тупых советов сходить к юристу...
есть статья 27 в которой сказано что сроки могут быть установлены.
есть статья 18 устанавливающая 5ти дневный срок устранения недостатков.
никакого упоминания про 30 дневный гарантийный ремонт в законе нет..
http://www.potrebitel.net/zakon/texts/zozpp/index.html
либо я плохо смотрю либо журналист слегка приврал...
Один из них высказал мысль, которую я стал понимать лишь спустя некоторое время:
Если резульат вашей работы плох - это обязательно заметят, но если результат вашей работы -хорош не ждите что вас похвалят.
По поводу применения "новых техник и финтов" - это все интересно пока есть время. Когда висит жесткий дед-лайн остается одно - фигачить...
но смущают завышенные и, по-моему, противоречивые требования инвесторов:
1) Каримов ищет проекты, которые носят глобальный характер - то есть те, продукция или услуги которых будут востребованы в разных странах и на больших по объему рынках.
2) Это должно быть запатентованное техническое решение.
Всвязи с этим возникают замечания:
- Получается что стартаперы должны получить патент американский или европейский патент. По-моему российские патенты не являются юридическим документов в международных судах (хотя могу ошибаться). А это сопряженно вообщем-то с некоторыми сложностями...
- Если попытаться представить себе ПРОДУКТ который создан небольшим стартапом и при этом продается во всем мире, то на ум приходят только небольшие програмки которые можно скачивать на сайтах типа download.com.
В остальных же случаях, чтобы продавать продукт по-всему миру, нужно быть не маленьким стартапом, а большой компанией с мощными маркетинговыми ресурсами. (Буду рад если меня переубедят и приведут примеры).
В штатах распространена концепция когда небольшие старт-апы разрабоатывают не продукт, а идею, некое частное техническое решение, которое затем может быть продано большими компаниям и использована в их продуктах. Но у нас, понятное дело, пока, такое невозможно.