1. Есть список заданий по проекту.
2. Каждому разработчику выдается одно задание. Срок не оговаривается -- когда сделаешь, тогда и сделаешь.
3. Оплата разработчику стабильно в месяц, никак не коррелирует с количеством/сложностью выполненных заданий.
4. Каждый раз при "разборе полетов" негативные высказывания о состоянии дел, мол все получается медленно и дорого, нужно что-то менять.
Здравствуйте, IObserver, Вы писали:
IO>Как вам такая схема работы:
IO>1. Есть список заданий по проекту.
Это плюс IO>2. Каждому разработчику выдается одно задание. Срок не оговаривается -- когда сделаешь, тогда и сделаешь.
Это не работает. Если сроков нет, то задача не будет сделана. IO>3. Оплата разработчику стабильно в месяц, никак не коррелирует с количеством/сложностью выполненных заданий.
Ничего не делаешь, а всё есть. IO>4. Каждый раз при "разборе полетов" негативные высказывания о состоянии дел, мол все получается медленно и дорого, нужно что-то менять.
Ну а то. IO>Работали ли вы по такой схеме? Как вы ее оцените?
У меня был такой стартап где не было сроков (проаботал пол года и свалил), стратап провалился.
Здравствуйте, Kernan, Вы писали:
IO>>2. Каждому разработчику выдается одно задание. Срок не оговаривается -- когда сделаешь, тогда и сделаешь. K>Это не работает. Если сроков нет, то задача не будет сделана.
Почему?
IO>>3. Оплата разработчику стабильно в месяц, никак не коррелирует с количеством/сложностью выполненных заданий. K>Ничего не делаешь, а всё есть.
05.10.2012 11:46, IObserver пишет:
> K>Это не работает. Если сроков нет, то задача не будет сделана. > > Почему?
Скорее всего они набирают таких сотрудников, которые что-то делают
только из-под палки.
Здравствуйте, IObserver, Вы писали:
IO>Здравствуйте, Kernan, Вы писали:
IO>>>2. Каждому разработчику выдается одно задание. Срок не оговаривается -- когда сделаешь, тогда и сделаешь. K>>Это не работает. Если сроков нет, то задача не будет сделана.
IO>Почему?
Например потому, что разработчик будет постоянно что-то улучшать или попробует применить забубенную технологию в которой он 0.
IO>>>3. Оплата разработчику стабильно в месяц, никак не коррелирует с количеством/сложностью выполненных заданий. K>>Ничего не делаешь, а всё есть.
IO>А как же доверие разработчикам?
Доверие — это хорошо, но любой даже самый ответственный человек будет подзабивать на работу мотивируя тем, что сделает ей через 3 года.
Здравствуйте, Vzhyk, Вы писали:
V>Скорее всего они набирают таких сотрудников, которые что-то делают V>только из-под палки.
Дело в том, что его слова соответствуют действительности.
И нет, работники и без палки делают. Но делают как им видтся правильным. То есть могут пол года шлифовать какое-либо задание, хотя для бизнеса такая шлифовка не нужна. Но ведь им об этом никто не сказал -- они должно быть сами это понимают.
То есть, таки получается, что сроки и менеджер должен быть. Хотя все мы люди разумные -- без управляющего "само собой" все не получается.
Или я не прав? Может у кого есть успешный опыт, когда не было никаких сроков, никаких проверок и все само собой получалось?
Здравствуйте, Vzhyk, Вы писали:
V>05.10.2012 11:46, IObserver пишет:
>> K>Это не работает. Если сроков нет, то задача не будет сделана. >> >> Почему? V>Скорее всего они набирают таких сотрудников, которые что-то делают V>только из-под палки.
Это не так
Здравствуйте, IObserver, Вы писали:
IO>Как вам такая схема работы:
IO>1. Есть список заданий по проекту. IO>2. Каждому разработчику выдается одно задание. Срок не оговаривается -- когда сделаешь, тогда и сделаешь.
Это очень плохо:
— могут прийти и сказать нам это нужно на завтра а у тебя готовность 25%;
— ты не знаешь чего ожидать: могут сказать что то ты там долго возишся пшел вон на улицу;
— непонятно какой уровень качества выбирать при старте разработки:
* прототип индусокода лишь бы работало в наиболее вероятных сценариях не предполагается что этот код будет развиваться и поддерживаться, а пойдет при первом же случае на помойку;
* качество что бы я мог понять что там и как работает, готовность кода к незначительным изменениям;
* качество понятное мне и соседям внутри компании как развивать и как поддерживать;
* SDK (что бы весь мир мог повторно использовать мои труды);
* NASA (SDK + абсолютно отказоустойчивый код в невероятных и непредсказуемых ситуациях)
Здравствуйте, 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:19, Kernan пишет:
> V>Скорее всего они набирают таких сотрудников, которые что-то делают > V>только из-под палки. > Это не так
"Это не работает. Если сроков нет, то задача не будет сделана." — ты писал.
По себе и своим знакомым с уверенностью могу сказать, что это не так.
Таким образом, вы специально таких людей отбираете, которые ничего не
делают, если их не пинать или делают вечно.
А вот когда начинает начальство сильно сроками на мозги капать, то срок
вырастает раза в 2-3 ("Вань, нада срочно, кровь из носу!!!". Ваня
делает, потом месяцами фиксятся баги. Ваня не специально их внес, просто
он сделал быстро, как требовали.)
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>Зачем? Не понимаю.
Потому что ему это интересно
