Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, eao197, Вы писали:
E>>Программисты здесь конечно не что-то уникальное. Наверняка есть еще масса профессий, в которых неожиданные авралы являются частью профессиональной специфики.
AVK>А с чего ты взял, что авралы это часть профессиональной специфики программирования?
Уважаемые читатели форума. На этом месте у нас с AndrewVK возник спор, который завершился моим обещанием, что я признаю свою неправоту, если большинство читателей укажут, что за последние 5 лет у них не было авралов на работе.
Поэтому прошу принять участие в нашем споре следующим образом: если у вас за последние 5 лет были авралы на работе, то поставьте на это сообщение "плюсик". Если не было -- минус.
Прошу просто подтверждать факт было/не было. Понятно, что аврал -- это не хорошо, поэтому не нужно своими оценками высказывать свое отрицательное/положительное отношение к этому явлению.
И еще одна штука -- у меня появилась мысль собрать и опубликовать коллекцию различных ситуаций, приведших к авралам/переработкам и пр. Если у кого-то есть желание поделиться своими воспоминаниями -- прошу присылать их мне на мыло: eao197 на yahoo com
Спасибо!
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Хочу заметить, что авралы не столько "следствие специфики программирования", сколько следствие комбинации человеческих слабостей и "специфики программирования" (точнее ситуации, когда можно некий период времени заниматься "черной магией" с обещанием результата "потом" и неумением "работодателя" проконтроллировать промежуточные результаты). В качестве иллюстрации: из друзей у меня программистов с гулькин нос, а авралы у них (не программистов) таки бывают.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Здравствуйте, eao197, Вы писали:
ANS>Хочу заметить, что авралы не столько "следствие специфики программирования", сколько следствие комбинации человеческих слабостей и "специфики программирования" (точнее ситуации, когда можно некий период времени заниматься "черной магией" с обещанием результата "потом" и неумением "работодателя" проконтроллировать промежуточные результаты). В качестве иллюстрации: из друзей у меня программистов с гулькин нос, а авралы у них (не программистов) таки бывают.
Я вовсе не хотел сказать, что программисты единственные, кто сталкивался с авралами. Более того, за прошедшее с моего высказывания время я прочел автобиографию Ричарда Брэнсона и пришел к выводу, что наши программиские авралы -- это так, еще цветочки.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Я вовсе не хотел сказать, что программисты единственные, кто сталкивался с авралами. Более того, за прошедшее с моего высказывания время я прочел автобиографию Ричарда Брэнсона
Здравствуйте, eao197, Вы писали:
E>Поэтому прошу принять участие в нашем споре следующим образом: если у вас за последние 5 лет были авралы на работе, то поставьте на это сообщение "плюсик". Если не было -- минус.
Ставлю минус. Во-первых, за постановку вопроса. Правильный вопрос, должен был прозвучать от тебя следующим образом: были ли у вас на работе за последние 5 лет периодические авралы, случающиеся постоянно. Во-вторых, у меня за последние 5 лет периодических авралов, случающихся постоянно не было.
Если нам не помогут, то мы тоже никого не пощадим.
E>Программисты здесь конечно не что-то уникальное. Наверняка есть еще масса профессий, в которых неожиданные авралы являются частью профессиональной специфики.
А с чего ты взял, что авралы это часть профессиональной специфики программирования?
Похоже, что я пропустил одно ключевое слово: "эпизодически". Я подразумевал "эпизодическое вкалывание до усеру".
Так что прошу привести мне цитату, где бы я говорил, что у любого программиста будут постоянные периодические авралы. Как метко заметил IT, это я про себя сказал
Здравствуйте, BulatZiganshin, Вы писали:
BZ>Здравствуйте, eao197, Вы писали:
E>>Я вовсе не хотел сказать, что программисты единственные, кто сталкивался с авралами. Более того, за прошедшее с моего высказывания время я прочел автобиографию Ричарда Брэнсона
BZ>за 17 минут?
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Deff, Вы писали:
S>>>Да ну, правда што ли? И какая же часть модели Изи и Оси описывает, к примеру, использование протоколом нижнего уровня протокола верхнего уровня? См. ICMP vs IP. D>>Не могу прокомментировать, т.к. ваша мысль мне непонятна. S>Поясняю мысль: TCP/IP не вырос из модели ISO/OSI. Он ей противоречит.
Признаю ошибку, TCP/IP не вырос из модели OSI.
формально она возникла между где-то между первой и четвертой версией стека TCP/IP,
меня видимо сбили с толку сходства в использовании вертикального
и горизонтального обмена данными в обоих.
D>>Концептуальность модели OSI просто не позволяет искать в ней описания тех или иных D>>аспектов реализации каких-либо стеков (т.к. последнее просто набор частностей). S>Вполне себе позволяет.
возможно, вы правы. видимо стоит лучше ознакомиться с наследием умершей ISO/OSI.
Здравствуйте, GlebZ, Вы писали:
GZ>Здравствуйте, shrecher, Вы писали:
S>>К счастью или к сожелению, весь процесс реализации распадаются на под задачи, каждая из которых, требует небольшого, но архитектурного решения, где требуется незаурядный мозг. Изначально идея проекта может быть очень классная, но чтобы ее осущетсвить нужны таланты. GZ>По опыту скажу так. Не столь важно что программа глючная, тормозная и т.д. Важна сама идея, и умение ее продать. И если ты не крутой монополист, то максимум чего произойдет — то что конкуренты напишут то же самое и пользователи постепенно уйдут к ним. Все продукты отличаются своими недостатками. Выигрывают те продукты, которые лучше умеют продавать.
вы ошибаетесь. Реализация идей важна неменьше (если не больше), чем сама концепция.
Пример gmail.com и yahoo!mail. Идея одна и таже, возможности продаж практически одинаковые. Но насколько gmail лучше yahoo! Удобнее, просто качественее, поэтому люди к и идут в gmail.
Сейчас, для каждой "крутой" идеи есть конкурент. Успех продукта определяется качеством его реализации.
Здравствуйте, eao197, Вы писали:
E>В ней говорилось, что один из типов безнадежных проектов -- это проекты, где сроки сдачи проектов на 50% меньше, чем это необходимо. Реализация такого проекта -- это сам по себе один сплошной аврал.
А еще говорилось, что для проектов длиной больше ~1 месяца сверхурочная работа не сокращает сроки, а увеличивает их. Потому что усталость накапливаются, люди делают больше ошибок и дольше их исправляют. Если работать в аврале достаточно долго, то эффективность становится отрицательной — то есть на исправление ошибок потом уйдет больше времени, чем на разработку той же функциональности с нуля в нормальном режиме работы.
Сократить сроки можно только за счет (а) урезания фич или (б) урезания этапа отладки и багфиксинга (который в нормальном проекте составляет около 2/3 общего срока). Нормальные менеджеры идут по пути (а), все остальные — по пути (б) и в результате получают очередное непригодное к нормальному употреблению угребище, но зато формально сделали всё что должны были и в срок.
Здравствуйте, Andrei F., Вы писали:
AF>Здравствуйте, eao197, Вы писали:
E>>В ней говорилось, что один из типов безнадежных проектов -- это проекты, где сроки сдачи проектов на 50% меньше, чем это необходимо. Реализация такого проекта -- это сам по себе один сплошной аврал.
AF>А еще говорилось, что для проектов длиной больше ~1 месяца сверхурочная работа не сокращает сроки, а увеличивает их. Потому что усталость накапливаются, люди делают больше ошибок и дольше их исправляют. Если работать в аврале достаточно долго, то эффективность становится отрицательной — то есть на исправление ошибок потом уйдет больше времени, чем на разработку той же функциональности с нуля в нормальном режиме работы. AF>Сократить сроки можно только за счет (а) урезания фич или (б) урезания этапа отладки и багфиксинга (который в нормальном проекте составляет около 2/3 общего срока). Нормальные менеджеры идут по пути (а), все остальные — по пути (б) и в результате получают очередное непригодное к нормальному употреблению угребище, но зато формально сделали всё что должны были и в срок.
Хороше описание очередной крайности. Для достоверности, однако, нужно подтвердить тезис об "очередном уробище". Или это из вашего личного опыта?
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Хороше описание очередной крайности. Для достоверности, однако, нужно подтвердить тезис об "очередном уробище". Или это из вашего личного опыта?
Это не крайность, это суровая правда жизни. Менеджер либо понимает, что дерево нельзя заставить расти быстрее, вытягивая его за верхушку, либо не понимает. Других вариантов нет.
И что тут подтверждать? Многие люди принципиально не ставят новые версии программ именно из этих соображений. "Вот выйдет первый сервиспак, тогда и поставлю". В опенсорсе всё вообще в открытую, нечетные билды — "нестабильные"
Здравствуйте, shrecher, Вы писали:
GZ>>Выигрывают те продукты, которые лучше умеют продавать.
S>вы ошибаетесь. Реализация идей важна неменьше (если не больше), чем сама концепция. S>Пример gmail.com и yahoo!mail. Идея одна и таже, возможности продаж практически одинаковые. Но насколько gmail лучше yahoo! Удобнее, просто качественее, поэтому люди к и идут в gmail.
Эээ — нет. Тут сыграла идея + сетевой маркетинг. Идея — 2 гигабайта для каждого + Ajax. 2 гига никто не предлагал. В основном у конкурентов было по 10-20 мегабайт. И об этом трубилось на каждом втором сайте связанных с интернетом. В том числе и на google.com. Ну а во вторых, сетевой маркетинг. В gmail можно было попасть только по приглашению. А запретный плод сладок. Скорость распространения такого маркетинга — экспоцентиальный. Были организованы сайты по раздаче запретного плода(не удивлюсь при помощи gmail, по крайней мере они не мешали). Вот и получилось что gmail захватил огромнейший сегмент рынка у огромного количества конкурентов(не только yahoo).
Что касается удобности, то тот же outlook на порядок удобнее. Структурировать письма неудобно. Мастера outlook на порядок удобнее. Я подписан на rsdn — мне пришлось спускать все rsdn-письма в корзину. Иначе я не разберусь с основной информацией. Через тегирование работать неудобно по сравнению с папками. Несколько ящиков можно настроить только через пересылку. Если ходить с медленной сети, то войти на него очень проблематично. Вобщем, много отстойного.
S>Сейчас, для каждой "крутой" идеи есть конкурент. Успех продукта определяется качеством его реализации.
Ты привел как раз пример гениальной идеи.
Специфика,
спецификум (отпозднелатинского specificus — особый, особенный), особенности, присущие только данному предмету, явлению или роду, классу предметов, явлении; существенные признаки, отличающие данный объект от всех других, например С. профессии летчика, С. искусства, С. издания.
БСЭ
Специфика,
AVK>спецификум (отпозднелатинского specificus — особый, особенный), особенности, присущие только данному предмету, явлению или роду, классу предметов, явлении; существенные признаки, отличающие данный объект от всех других, например С. профессии летчика, С. искусства, С. издания.
AVK>БСЭ
И?
Где я утвержал, что "специфика программирования" == авралы? Если я правильно понимаю наш спор, ты мы выясняем, являются ли авралы частью специфики программированием (на ряду с другими явлениями) или не являются.
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, minorlogic, Вы писали:
M>>Не подтосовывай факты , речь шла о ПОСТОЯННЫХ , ПЕРИОДИЧЕСКИХ авралах , а раз в 5 лет бывает аврал и у дворника
E>Где она шла об этом? E>Спор начался отсюда: http://www.rsdn.ru/forum/message/2733239.1.aspx
E>[q] E>>Программисты здесь конечно не что-то уникальное. Наверняка есть еще масса профессий, в которых неожиданные авралы являются частью профессиональной специфики.
Тогда поясни, что такое "профессиональная специфика" ? то что бывает на работе раз в 5 лет ? у меня за 5 лет даже не раз понос был (извините за подробность), это "профессиональная специфика" ?
'When I use a word,' Humpty Dumpty said in rather a scornful tone, 'it means just what I choose it to mean--neither more nor less.'
Если нам не помогут, то мы тоже никого не пощадим.
