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

IO>Как вам такая схема работы:

IO>1. Есть список заданий по проекту.
IO>2. Каждому разработчику выдается одно задание. Срок не оговаривается -- когда сделаешь, тогда и сделаешь.

Это очень плохо:
— могут прийти и сказать нам это нужно на завтра а у тебя готовность 25%;
— ты не знаешь чего ожидать: могут сказать что то ты там долго возишся пшел вон на улицу;
— непонятно какой уровень качества выбирать при старте разработки:

* прототип индусокода лишь бы работало в наиболее вероятных сценариях не предполагается что этот код будет развиваться и поддерживаться, а пойдет при первом же случае на помойку;
* качество что бы я мог понять что там и как работает, готовность кода к незначительным изменениям;
* качество понятное мне и соседям внутри компании как развивать и как поддерживать;
* SDK (что бы весь мир мог повторно использовать мои труды);
* NASA (SDK + абсолютно отказоустойчивый код в невероятных и непредсказуемых ситуациях)

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

V>05.10.2012 16:59, UA пишет:

>> а о его стиле писать
>> быстро, много и не понятного кода никому другому.
V>А вот так не умел писать никогда.
V>Таков мой стиль мышления. Часто, лучше, если я несколько дней вообще ни
V>строчки кода не напишу, чем напишу их кучу — все одно выкинуть придется.
V>Одно время вообще по рукам себя бил, если тянуло сделать больше, чем
V>запланировал на день, ибо назавтра очень часто весь этот код выкидывал.

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

>> Ну то есть если вам скажут что это нужно оооочень срочно, вы сорвете
>> сроки потому что ваш default quality level требует намного больше времени?
V>Да. НЕ просто сорву, я вообще на них забью. Чем более глуп и безграмотен
V>манагер, тем больше он подобной чуши несет.

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

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

IO>Как вам такая схема работы:

IO>1. Есть список заданий по проекту.
Это плюс
IO>2. Каждому разработчику выдается одно задание. Срок не оговаривается -- когда сделаешь, тогда и сделаешь.
Это не работает. Если сроков нет, то задача не будет сделана.
IO>3. Оплата разработчику стабильно в месяц, никак не коррелирует с количеством/сложностью выполненных заданий.
Ничего не делаешь, а всё есть.
IO>4. Каждый раз при "разборе полетов" негативные высказывания о состоянии дел, мол все получается медленно и дорого, нужно что-то менять.
Ну а то.
IO>Работали ли вы по такой схеме? Как вы ее оцените?
У меня был такой стартап где не было сроков (проаботал пол года и свалил), стратап провалился.

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

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

IO>>>2. Каждому разработчику выдается одно задание. Срок не оговаривается -- когда сделаешь, тогда и сделаешь.
K>>Это не работает. Если сроков нет, то задача не будет сделана.

IO>Почему?
Например потому, что разработчик будет постоянно что-то улучшать или попробует применить забубенную технологию в которой он 0.

IO>>>3. Оплата разработчику стабильно в месяц, никак не коррелирует с количеством/сложностью выполненных заданий.
K>>Ничего не делаешь, а всё есть.

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

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

ты не находишь противоречия между "медленно и дорого" и содержанием пунктов 2 и 3 ?

05.10.2012 13:19, Kernan пишет:

> V>Скорее всего они набирают таких сотрудников, которые что-то делают
> V>только из-под палки.
> Это не так
"Это не работает. Если сроков нет, то задача не будет сделана." — ты писал.
По себе и своим знакомым с уверенностью могу сказать, что это не так.
Таким образом, вы специально таких людей отбираете, которые ничего не
делают, если их не пинать или делают вечно.
А вот когда начинает начальство сильно сроками на мозги капать, то срок
вырастает раза в 2-3 ("Вань, нада срочно, кровь из носу!!!". Ваня
делает, потом месяцами фиксятся баги. Ваня не специально их внес, просто
он сделал быстро, как требовали.)

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

V>Скорее всего они набирают таких сотрудников, которые что-то делают
V>только из-под палки.

Дело в том, что его слова соответствуют действительности.

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

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

Или я не прав? Может у кого есть успешный опыт, когда не было никаких сроков, никаких проверок и все само собой получалось?

Как вам такая схема работы:

1. Есть список заданий по проекту.
2. Каждому разработчику выдается одно задание. Срок не оговаривается -- когда сделаешь, тогда и сделаешь.
3. Оплата разработчику стабильно в месяц, никак не коррелирует с количеством/сложностью выполненных заданий.
4. Каждый раз при "разборе полетов" негативные высказывания о состоянии дел, мол все получается медленно и дорого, нужно что-то менять.

Работали ли вы по такой схеме? Как вы ее оцените?

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

IO>>2. Каждому разработчику выдается одно задание. Срок не оговаривается -- когда сделаешь, тогда и сделаешь.
K>Это не работает. Если сроков нет, то задача не будет сделана.

Почему?

IO>>3. Оплата разработчику стабильно в месяц, никак не коррелирует с количеством/сложностью выполненных заданий.
K>Ничего не делаешь, а всё есть.

А как же доверие разработчикам?

05.10.2012 11:46, IObserver пишет:

> K>Это не работает. Если сроков нет, то задача не будет сделана.
>
> Почему?
Скорее всего они набирают таких сотрудников, которые что-то делают
только из-под палки.

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

V>05.10.2012 11:46, IObserver пишет:

>> K>Это не работает. Если сроков нет, то задача не будет сделана.
>>
>> Почему?
V>Скорее всего они набирают таких сотрудников, которые что-то делают
V>только из-под палки.
Это не так

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

IO>Работали ли вы по такой схеме? Как вы ее оцените?

VAX/VMS делали по такой схеме. Оооочень приятная была операционная система.

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

IO>Как вам такая схема работы:

IO>1. Есть список заданий по проекту.
IO>2. Каждому разработчику выдается одно задание. Срок не оговаривается -- когда сделаешь, тогда и сделаешь.
IO>3. Оплата разработчику стабильно в месяц, никак не коррелирует с количеством/сложностью выполненных заданий.
IO>4. Каждый раз при "разборе полетов" негативные высказывания о состоянии дел, мол все получается медленно и дорого, нужно что-то менять.

IO>Работали ли вы по такой схеме? Как вы ее оцените?

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

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

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

V_S>ты не находишь противоречия между "медленно и дорого" и содержанием пунктов 2 и 3 ?

Не понял почему противоречие. Скорее наоборот, одно строго вытекает из другого.

05.10.2012 13:18, IObserver пишет:

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

> То есть, таки получается, что сроки и менеджер должен быть. Хотя все мы
> люди разумные -- без управляющего "само собой" все не получается.
>
> Или я не прав? Может у кого есть успешный опыт, когда не было никаких
> сроков, никаких проверок и все само собой получалось?
Это твои фантазии и ничего более.

05.10.2012 13:18, Kernan пишет:

> Например потому, что разработчик будет постоянно что-то улучшать или
> попробует применить забубенную технологию в которой он 0.
Зачем? Не понимаю.

05.10.2012 13:26, alpha21264 пишет:

> VAX/VMS делали по такой схеме. Оооочень приятная была операционная система.
Кстати да. Очень мне когда-то понравилась на фоне EC.

05.10.2012 13:50, UA пишет:

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

> * качество что бы я мог понять что там и как работает, готовность
> кода к незначительным изменениям;
Не умею.

> * качество понятное мне и соседям внутри компании как развивать и
> как поддерживать;
Умею.

> * SDK (что бы весь мир мог повторно использовать мои труды);
Умею.

> * NASA (SDK + абсолютно отказоустойчивый код в невероятных и
> непредсказуемых ситуациях)
Не в NASA работаю. Не пришлось так писать.

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

UA>- непонятно какой уровень качества выбирать при старте разработки:
Это очень важное качество для хорошего разработчика. ПМ (проект-менеджер) может хотеть что-то в определенный срок и должен озвучить его. Задача разработчика:
1) Изложить полный объем, показать все задачи, которые надо сделать (из того, что он на данный момент видит)
2) Что он реально сможет выдать за такое время

Далее согласование и корректировка плана.

Если ПМ сам хорошо разбирается в теме, то может задать и необходимый уровень ожидаемого качества. Это сильно облегчит работу разработчику.

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

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

Делают, но то что им нравится, а не то что нужно для бизнеса.

И не вечно, а просто очень долго.

V>А вот когда начинает начальство сильно сроками на мозги капать, то срок
V>вырастает раза в 2-3 ("Вань, нада срочно, кровь из носу!!!". Ваня
V>делает, потом месяцами фиксятся баги. Ваня не специально их внес, просто
V>он сделал быстро, как требовали.)

Вот это ключевой момент: баланс между сроками и качеством. Действительно, можно сделать очень быстро, но потом долго рефакторить и переписать с нуля.

То, о чем вы говорите -- как раз свойственно для схем, в которых нет конктретных сроков.

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

V>05.10.2012 13:18, Kernan пишет:

>> Например потому, что разработчик будет постоянно что-то улучшать или
>> попробует применить забубенную технологию в которой он 0.
V>Зачем? Не понимаю.
Потому что ему это интересно

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

V>05.10.2012 13:50, UA пишет:

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

Сэмулировать уровень студента не можете? не верю

>> * качество что бы я мог понять что там и как работает, готовность
>> кода к незначительным изменениям;
V>Не умею.

И уровень Junior Developer — не можете?

>> * качество понятное мне и соседям внутри компании как развивать и
>> как поддерживать;
V>Умею.

>> * SDK (что бы весь мир мог повторно использовать мои труды);
V>Умею.

Как вы могли пройти до этого уровня не пройдя базовые уровни? Для меня загадка

>> * NASA (SDK + абсолютно отказоустойчивый код в невероятных и
>> непредсказуемых ситуациях)
V>Не в NASA работаю. Не пришлось так писать.

Это долго, дорого и офигенно — не всем такое нужно на самом деле.

05.10.2012 15:26, IObserver пишет:

> Делают, но то что им нравится, а не то что нужно для бизнеса.
Если вы заставляется людей делать то, что им не нравиться, то это еще
хуже для вашего бизнеса. Программистов достаточно много и всегда, если
есть желание можно найти тех, которым будет нравиться то, что вам нужно.

> И не вечно, а просто очень долго.
Либо задача действительно сложная или объемная или от такого сотрудника
надо избавляться.

> V>А вот когда начинает начальство сильно сроками на мозги капать, то срок
> V>вырастает раза в 2-3 ("Вань, нада срочно, кровь из носу!!!". Ваня
> V>делает, потом месяцами фиксятся баги. Ваня не специально их внес, просто
> V>он сделал быстро, как требовали.)
>
> Вот это ключевой момент: баланс между сроками и качеством.
Но, например я, не могу писать код качества ниже какого-то, как ни
старался и посему давно уже плюю на пожелания таких начальников. Не, я
их не посылаю, а грю: "ОК". И делаю, как мне удобно. И в 100% начальники
удовлетворяются. А вот если шел на поводу у таких — возникало много
проблем у меня.

> То, о чем вы говорите -- как раз свойственно для схем, в которых нет
> конктретных сроков.
Это зависит от задач.

З.Ы. Возможно ты слишком оптимистичен в своих ожиданиях по срокам? Таких
начальников 95%, особенно среди молодых.

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

V>05.10.2012 13:18, Kernan пишет:

>> Например потому, что разработчик будет постоянно что-то улучшать или
>> попробует применить забубенную технологию в которой он 0.
V>Зачем? Не понимаю.
Потому, что может. Разве тебе не хотелось бы применить свой любимый язык Немерле на работе? Ну применил ты, вылезли баги или закопался в чём-то. Не понравилось тебя, взял и переделал по другому. Или прочитал статью и начал перделывать используя новый подход. Не надо думать, что программисты все ориентиорованы на качественный результат и являются поголовно адекватными людьми. И не надо судить людей по себе.

05.10.2012 15:29, nightcode пишет:

>>> Например потому, что разработчик будет постоянно что-то улучшать или
>>> попробует применить забубенную технологию в которой он 0.
> V>Зачем? Не понимаю.
> Потому что ему это интересно
Таких я практически не видел, которым нечто интересно улучшать в коде до
бесконечности (мы же не про науку говорим?). И чаще проявляется у очень
молодых программистов.
Изучать очередную новую технологию? Есть такое в подавляющем большинстве
у очень молодых. После 5-10 уже не интересно.
Может проблема в том, что слишком много молодых и зеленых на конторе?
Может следовало бы костяк конторы из более опытных делать (со стажем
10-20 лет)?

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

V>05.10.2012 13:19, Kernan пишет:

>> V>Скорее всего они набирают таких сотрудников, которые что-то делают
>> V>только из-под палки.
>> Это не так
V>"Это не работает. Если сроков нет, то задача не будет сделана." — ты писал.
V>По себе и своим знакомым с уверенностью могу сказать, что это не так.
V>Таким образом, вы специально таких людей отбираете, которые ничего не
V>делают, если их не пинать или делают вечно.
Можно делать медленно почитывая РСДН, можно смотреть кинцо и ковырять какой-нибудь фреймворк, дело не в людях, а в цели. Живой организм всегда идёт по пути наименьшего сопротивления. На эут тему есть замечательный афоризм у Конфуция который я забыл, но суть такова, что если ты не будешь видеть цель, то будешь ходить кругами или не туда.

V>А вот когда начинает начальство сильно сроками на мозги капать, то срок
V>вырастает раза в 2-3 ("Вань, нада срочно, кровь из носу!!!". Ваня
V>делает, потом месяцами фиксятся баги. Ваня не специально их внес, просто
V>он сделал быстро, как требовали.)
Ты не про сроки говоришь, а дурацкий менеджмент. По факту, сроки устанавливает программист когда к нему приходят и спрашивают за сколько ты сделаешь "это? А то, что ты описал происходит из-за дураков, которые подписываются под сроками в которые не уложаться, а потом прикрывая сою задницу начинают капать на мозги.

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

IO>Как вам такая схема работы:

IO>1. Есть список заданий по проекту.
IO>2. Каждому разработчику выдается одно задание. Срок не оговаривается -- когда сделаешь, тогда и сделаешь.
IO>3. Оплата разработчику стабильно в месяц, никак не коррелирует с количеством/сложностью выполненных заданий.
IO>4. Каждый раз при "разборе полетов" негативные высказывания о состоянии дел, мол все получается медленно и дорого, нужно что-то менять.

IO>Работали ли вы по такой схеме? Как вы ее оцените?
Сильно зависит от деловой атмосферы в коллективе. Если каждый день сверки и обсуждения. Поощряется инициатива и творческий подход то вполне работоспособная система.

05.10.2012 16:20, Kernan пишет:

> Можно делать почитывая РСДН,
Что я и делаю. А вообще я насмотрелся кода тех, кто десятипальцевым
методом его набирает.

> Живой организм всегда
> идёт по пути наименьшего сопротивления.
Значит я мертвый организм, ибо в твоем понимании не иду по пути
наименьшего сопротивления.

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

05.10.2012 16:08, Kernan пишет:

> Потому, что может. Разве тебе не хотелось бы применить свой любимый язык
> Немерле на работе?
Нет. Никогда. Чаще было, когда есть некий язык, который более подходит
для задачи, но ты его не знаешь, а знаешь другой, который менее. И,
самое разумное взять неделю времени, изучить его и решить задачу на нем.
Но обычно есть манагер, который хочет вчера и время на изучение не дает,
посему делаешь задачу на том, что знаешь, причем затратив на нее времени
больше, чем если бы изучил тот и сделал задачу на нем.

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

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

05.10.2012 15:58, UA пишет:

> Сэмулировать уровень студента не можете? не верю
Сколько у тебя опыт работы? Очень удивлюсь, если после 20 лет опыта
сможешь. Я же писал уже тут, как специально недавно сходил на
собеседование и не смог ответить на простейший вопрос, хотя этот момент
постоянно использую в работе, но уже лет как 5 не задумываясь. Просто
знаю что так писать надо, а так не надо, а почему уже и не вспомню.

> И уровень Junior Developer — не можете?
Я вообще этой градации не понимаю. Просто после какого-то опыта работы
программист пишет не задумываясь, как по-русски

> Как вы могли пройти до этого уровня не пройдя базовые уровни? Для меня
> загадка
Почему, прошел, много много лет назад. И понятно, что если на конторе
одни "студенты", то за ними нужен глаз да глаз.

05.10.2012 16:21, batu пишет:

> Сильно зависит от деловой атмосферы в коллективе. Если каждый день
> сверки и обсуждения.
Каждый день не надо. Достаточно раз в 1-2 недели. Но понятно, что должна
быть некая система, где каждый отражает текущее состояние.

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

V>05.10.2012 16:20, Kernan пишет:

>> Можно делать почитывая РСДН,
V>Что я и делаю. А вообще я насмотрелся кода тех, кто десятипальцевым
V>методом его набирает.
Разговор не о том.

>> Живой организм всегда
>> идёт по пути наименьшего сопротивления.
V>Значит я мертвый организм, ибо в твоем понимании не иду по пути
V>наименьшего сопротивления.
Идёшь. Просто те энергетические затраты которые ты делаешь сейчас тебя устраивают. Как только появится сложная задача
ты будешь пытаться минимизировать затраты энергии.

>> Ты не про сроки говоришь, а дурацкий менеджмент. По факту, сроки
>> устанавливает программист когда к нему приходят и спрашивают за сколько
>> ты сделаешь "это?
V>Т.е сроки уже появились. Хорошо. Причем их не некий недоманагер
V>определил. Но, такой нюанс, что в зависимости от задачи, квалификации и
V>опыта работы этого программиста его оценка может ошибаться в 100 раз.
Может. Вот тут манагер использует особую манагерскую магию и превращает сроки в... большие сроки.

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

V>05.10.2012 15:58, UA пишет:

>> Сэмулировать уровень студента не можете? не верю
V>Сколько у тебя опыт работы? Очень удивлюсь, если после 20 лет опыта
V>сможешь. Я же писал уже тут, как специально недавно сходил на
V>собеседование и не смог ответить на простейший вопрос, хотя этот момент
V>постоянно использую в работе, но уже лет как 5 не задумываясь. Просто
V>знаю что так писать надо, а так не надо, а почему уже и не вспомню.

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

>> И уровень Junior Developer — не можете?
V>Я вообще этой градации не понимаю. Просто после какого-то опыта работы
V>программист пишет не задумываясь, как по-русски

Ну то есть если вам скажут что это нужно оооочень срочно, вы сорвете сроки потому что ваш default quality level требует намного больше времени?

05.10.2012 16:55, Kernan пишет:

>>> Живой организм всегда
>>> идёт по пути наименьшего сопротивления.
> V>Значит я мертвый организм, ибо в твоем понимании не иду по пути
> V>наименьшего сопротивления.
> Идёшь. Просто те энергетические затраты которые ты делаешь сейчас тебя
> устраивают. Как только появится сложная задача
> ты будешь пытаться минимизировать затраты энергии.
Наоборот. Мне очень не нравятся рутинные, а сложные нравятся и я
постоянно ввязываюсь в такие. И затраты энергии я не минимизирую. Зачем?

> Может. Вот тут манагер использует особую манагерскую магию и превращает
> сроки в... большие сроки.
И ошибается ровно также, ибо понимает в задаче еще меньше программиста того.

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

V>05.10.2012 16:21, batu пишет:

>> Сильно зависит от деловой атмосферы в коллективе. Если каждый день
>> сверки и обсуждения.
V>Каждый день не надо. Достаточно раз в 1-2 недели. Но понятно, что должна
V>быть некая система, где каждый отражает текущее состояние.
Не вижу особых проблем с полчаса каждый день уделить общему совещанию о текущем состоянии дел.. Если в проекте не больше 7 человек..

05.10.2012 16:59, UA пишет:

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

> Ну то есть если вам скажут что это нужно оооочень срочно, вы сорвете
> сроки потому что ваш default quality level требует намного больше времени?
Да. НЕ просто сорву, я вообще на них забью. Чем более глуп и безграмотен
манагер, тем больше он подобной чуши несет.

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

V>05.10.2012 16:08, Kernan пишет:

V>Но обычно есть манагер, который хочет вчера и время на изучение не дает,
V>посему делаешь задачу на том, что знаешь, причем затратив на нее времени
V>больше, чем если бы изучил тот и сделал задачу на нем.
Это если твой бэкграунд позваляет. А если нет, но ты чётко знаешь, что этот язык позволит элегантнее решить пробелму, что тогда?

V>Скользкий момент — сильно зависит от ситуации. Но обычно завершаю, как
V>есть, а потом делаю с новым подходом, если надо. Чаще всего оказывается
V>надо.
А будь у тебя бесконечное время? Скорее всего ты переделаешь.

V>Я стараюсь думать о людях хорошо, пока они не убеждают меня в обратном.
Мой поинт не в том, что наду думать хорошо/плохо, а в том, что надо думать про о том, что они другие. С другим мышлением и мировоззрением, отличным от твоего.

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

IO>Как вам такая схема работы:

IO>1. Есть список заданий по проекту.
IO>2. Каждому разработчику выдается одно задание. Срок не оговаривается -- когда сделаешь, тогда и сделаешь.
IO>3. Оплата разработчику стабильно в месяц, никак не коррелирует с количеством/сложностью выполненных заданий.
IO>4. Каждый раз при "разборе полетов" негативные высказывания о состоянии дел, мол все получается медленно и дорого, нужно что-то менять.

IO>Работали ли вы по такой схеме? Как вы ее оцените?

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

05.10.2012 17:11, Kernan пишет:

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

> А будь у тебя бесконечное время? Скорее всего ты переделаешь.
Конечно. Но в реальности его-то и нет. Срок жизни-то наш ограничен.

05.10.2012 17:29, UA пишет:

> Поздравляю, вы сорвали презентацию демы которая являлась как условие для
> получения контракта на 10 мегабаксов. Вы уволены!
)))))))). Давно так не ржал. Напугали ежа голой задницей.
Это манагер пусть развлекается дальше с "топами", я так так и скажу
вышестоящему начальству, что я его предупреждал, что ничего не выйдет,
он меня не послушал и не согласовал с заказчиком более адекватные сроки
или объем работы.

У меня и более веселые случаи были. Обычно манагеры те или начинали
головой думать или были увольняемы. Один такой Интелу так и переслал мою
с ним переписку, где я, чтобы не поднимать ненужный срач, так и написал
ему, что да я не успел сделать то, что он напланировал. Как думаешь у
кого проблемы были?

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

V>Может проблема в том, что слишком много молодых и зеленых на конторе?
V>Может следовало бы костяк конторы из более опытных делать (со стажем
V>10-20 лет)?

Вы, видимо, и сами командой управлять сможете?

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

05.10.2012 18:23, IObserver пишет:

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

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

V>05.10.2012 17:29, UA пишет:

>> Поздравляю, вы сорвали презентацию демы которая являлась как условие для
>> получения контракта на 10 мегабаксов. Вы уволены!
V>)))))))). Давно так не ржал. Напугали ежа голой задницей.
V>Это манагер пусть развлекается дальше с "топами", я так так и скажу
V>вышестоящему начальству, что я его предупреждал, что ничего не выйдет,
V>он меня не послушал и не согласовал с заказчиком более адекватные сроки
V>или объем работы.

Но ведь конкурирующая фирма которая выиграла конкурс сделала это силами зеленого студента (он сделал это быстро и некачественно но этого было достаточно для презентации), как вы это им обьясните?

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

IO>2. Каждому разработчику выдается одно задание. Срок не оговаривается -- когда сделаешь, тогда и сделаешь.
IO>Работали ли вы по такой схеме? Как вы ее оцените?

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

IO>1. Есть список заданий по проекту.
хорошо

IO>2. Каждому разработчику выдается одно задание. Срок не оговаривается -- когда сделаешь, тогда и сделаешь.
лучше определить Hero-line и Deadline
если успеет раньше Hero — поощрять
если не успевает за Deadline — должен объяснить почему

IO>3. Оплата разработчику стабильно в месяц, никак не коррелирует с количеством/сложностью выполненных заданий.
часто вынужденно так бывает, но не очень хорошо

IO>4. Каждый раз при "разборе полетов" негативные высказывания о состоянии дел, мол все получается медленно и дорого, нужно что-то менять.
лучше говорить конкретно почему всё плохо и кто козёл, причём лично ему
и плохо, если придираться из-за того, что всё плохо вцелом, к чему-то не имеющему отношения к настоящей причине промаха

IO>Работали ли вы по такой схеме? Как вы ее оцените?
да работал
для моего самоощущения даже лучше когда ставят рамки
иначе теряется ориентация — хорошо я работаю, плохо — иногда гнетёт, даже если мной на самом деле довольны

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

V>05.10.2012 13:18, Kernan пишет:

>> Например потому, что разработчик будет постоянно что-то улучшать или
>> попробует применить забубенную технологию в которой он 0.
V>Зачем? Не понимаю.

Resume-driven development. А как еще об украшении своего резюме заботиться, не "разводя" руководство на применение новых баззвордов?

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

IO>Как вам такая схема работы:

IO>1. Есть список заданий по проекту.
IO>2. Каждому разработчику выдается одно задание. Срок не оговаривается -- когда сделаешь, тогда и сделаешь.

А если задачи связаны друг с другом ? Да и собственно, если делается продукт, то у него должен быть срок выхода. Хотя бы ориентировочный. Потом, помимо программистов есть тестеры, тех писатели (документация, help), локализаторы и т.п. Как всех синхронизировать, если каждый делает задачи сколько влезет ?

05.10.2012 18:46, UA пишет:

> Но ведь конкурирующая фирма которая выиграла конкурс сделала это силами
> зеленого студента (он сделал это быстро и некачественно но этого было
> достаточно для презентации), как вы это им обьясните?
Кому объяснять? Что? Что кто-то там что-то сделал (или не сделал), при
этом загорая на Канарах (силами зеленого студента).
Это их проблемы, я не мои. Тех кто "сделал".

06.10.2012 10:38, senglory пишет:

> Resume-driven development. А как еще об украшении своего резюме
> заботиться, не "разводя" руководство на применение новых баззвордов?\
Ужас какой. Обычно думаешь, что из резюме повыкидывать, а не каких новых
баззвордов добавить.

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

V>06.10.2012 10:38, senglory пишет:

>> Resume-driven development. А как еще об украшении своего резюме
>> заботиться, не "разводя" руководство на применение новых баззвордов?\
V>Ужас какой. Обычно думаешь, что из резюме повыкидывать, а не каких новых
V>баззвордов добавить.

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

IO>Как вам такая схема работы:

IO>1. Есть список заданий по проекту.
IO>2. Каждому разработчику выдается одно задание. Срок не оговаривается -- когда сделаешь, тогда и сделаешь.
IO>3. Оплата разработчику стабильно в месяц, никак не коррелирует с количеством/сложностью выполненных заданий.
IO>4. Каждый раз при "разборе полетов" негативные высказывания о состоянии дел, мол все получается медленно и дорого, нужно что-то менять.

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