Прикольно было бы самому подбирать звук (думаю, умельцы найдутся).
Я бы записал звук старого-старого запорожца. Чтобы глушитель издавал хлопки, а мотор работал со скрежетом ;)
1) А вот как раз разницу в трудозатратах надо продумать очень тщательно. Но, думаю, грамотно выбранная стратегия «перехода» из команды в команды может сильно помочь и упростить это все.
Как вариант — строгое деление команд по «модульному» признаку. Например:
Надо сделать сайт. Что мы имеем:
На 1-м этапе работает команда PM, она разрабатывает ТЗ и продумывает все, что надо.
Потом к ней подсоединяются, скажем, команды «кодеров» и дизайнеров. Идет активная стадия разработки.
И на последнем этапе подключается команда тестеров. При этом команда PM на всех этапах не покидает проект. Они и кодируют, и дизайном занимаются и т.д. (какой же ты специалист, если не занимаешься практическим применением своих навыков. Пусть будут «старшими» товарищами для остальных). В этом случае команда PM полностью контролирует процесс разработки, она определяет численность команды и ее специфику.
Если команды делать небольшими (скажем, по 3-5 человек), то можно довольно «динамично» варьировать текущую нагрузку по проекту. А когда кто-нибудь решит, что он готов к образованию своей команды — у него все карты на руках :)…
2) Я имел в виду, что человек переходит на новый проект внутри компании, при этом «бросая» старый. Минус в том, что если появился «денежный» проект, то старый может остаться без разработчиков. Способ обхода данного момента — обмен, а не переход. Т.е. ты не уходишь, а меняешься с человеком проектом (конечно, можно и переход предусмотреть, но уже с ограничениями, когда можно, а когда нельзя). Но тут тоже минус — не все разработчики обладают равной квалификацией. (Выход — пусть и с командой согласовываются все переходы). Но опять же проблема: а как рассчитывать вклад каждого в проект?
5+6) Рекомендуется оценивать сроки именно человеку, который будет это все реализовывать (в этом случае сроки самые маленькие получаются). Можно дать возможность команде на 1-м этапе составить ТЗ и примерные сроки. Потом дать им возможность или сменить проект или разработать его. За разработку ТЗ давать некий % от цены.
В этом случае есть есть несколько вариантов:
1) Разработал ТЗ и реализовал — все хорошо
2) ТЗ, но без реализации — в этом случае можно брать другую команду, пускай она оценит сама сроки и реализовывает (тут можно и по срокам сравнить).
3) Находишь проект с ТЗ и делаешь его.
Т.е. получается самоорганизация: Ты или только с ТЗ можешь работать, или только по ТЗ, или полный цикл. Все сами выбирают то, что им больше нравится и лучше получается (врятли любитель составлять ТЗ, но у которого это не выходит сумеет «продать» свое ТЗ другой команде).
Еще надо продумать момент, что иногда у команд разные спецификации. Скажем, одна — программисты, другая — дизайнеры/тестеры и т.д. В этом случае тоже надо продумать коммуникацию между ними.
4) про монеты. А почему фальшивые поровну между чашечками весов поделились? Может и такое, что все фальшивые появятся на 1 чашечке.
1) (40!) Да, верно (Когда решал, думал, что придется вспоминать и другие признаки делимости ;))
5) (4х1+5х0) А как быть с тем, что количество чисел уменьшается (написали 1, стерли 2?). В итоге 1 число останется, значит все числа и равны между собой. (может, я задачу не так понял?)
Интересно, а есть ли плагины, позволяющие не только использовать properties в описании класса, но и при его использовании?
Например, чтобы вместо
a = obj.getProp() писать a = obj.Prop, который в дальнейшем транслировался бы именно в getter?
Что же, идея хорошая, но и минусов в ней достаточно (не бывает "+" без "-"). Конечно, минусы на практике можно попытаться обратить и в "+", но тут нужно и полное понимание всего механизма работы такой организации не только «верхам», но и «низам»…
В реальности, чтобы такое заработало — надо просто взять и сделать ;) Да, рискованно; да, страшно, но без практического внедрения это все остается только идеями и далее ни куда не уходит…
Какие я вижу минусы:
1) Заказчик 1 — у него, соответственно, монополия на заказы… В принципе, решается введением еще нескольких начальников (заказчиков).
2) Есть возможность у исполнителя уйти на более интересный проект (мало ли что, такое запрещать нельзя, ведь насильно мил не будешь :)), в этом случае появляется опасность того, что ключевой разработчик просто уйдет.
3) А что в плане з/п? Если комбинировать — то откуда брать постоянную часть зарплаты, если команд разработки много, а заказов мало? «Нахлебников» терпеть особо не любят…
4) Санкции на невыполнение работы — не есть хорошо.
5) Кто будет устанавливать сроки? Если ты изначально неправильно оценил объем работ или заказ поменялся, то все летит кувырком…
6) Как и было сказано, нужно проработанное ТЗ, что значит, что его надо проработать. А кто этим занимается? Лучше всего, когда этим занимается именно тот человек, кто будет непосредственно реализовывать это все…
В принципе, список можно продолжать… Все это требует более глубокой проработки, но и пока не попробуешь на практике, не поймешь всех минусов, а часть может оказаться надуманной…
К очкам еще и комплекс упражнений идет для увеличения эффекта.
Еще про очки могу сказать, что они помогают восстановить зрение только до того уровня, который мы видим прищурившись (могу и ошибаться, но врач так рассказывал)…
Восстановить можно и безоперационным методом. Но до определенного уровня (не на все 100%). На сколько знаю, некоторые клиники предлагают спец. курс даже (но его и дома можно повторить без проблем). Я не спец в данном вопросе, так что лучше проконсультироваться со специалистом ;).
Я бы записал звук старого-старого запорожца. Чтобы глушитель издавал хлопки, а мотор работал со скрежетом ;)
Как вариант — строгое деление команд по «модульному» признаку. Например:
Надо сделать сайт. Что мы имеем:
На 1-м этапе работает команда PM, она разрабатывает ТЗ и продумывает все, что надо.
Потом к ней подсоединяются, скажем, команды «кодеров» и дизайнеров. Идет активная стадия разработки.
И на последнем этапе подключается команда тестеров. При этом команда PM на всех этапах не покидает проект. Они и кодируют, и дизайном занимаются и т.д. (какой же ты специалист, если не занимаешься практическим применением своих навыков. Пусть будут «старшими» товарищами для остальных). В этом случае команда PM полностью контролирует процесс разработки, она определяет численность команды и ее специфику.
Если команды делать небольшими (скажем, по 3-5 человек), то можно довольно «динамично» варьировать текущую нагрузку по проекту. А когда кто-нибудь решит, что он готов к образованию своей команды — у него все карты на руках :)…
5+6) Рекомендуется оценивать сроки именно человеку, который будет это все реализовывать (в этом случае сроки самые маленькие получаются). Можно дать возможность команде на 1-м этапе составить ТЗ и примерные сроки. Потом дать им возможность или сменить проект или разработать его. За разработку ТЗ давать некий % от цены.
В этом случае есть есть несколько вариантов:
1) Разработал ТЗ и реализовал — все хорошо
2) ТЗ, но без реализации — в этом случае можно брать другую команду, пускай она оценит сама сроки и реализовывает (тут можно и по срокам сравнить).
3) Находишь проект с ТЗ и делаешь его.
Т.е. получается самоорганизация: Ты или только с ТЗ можешь работать, или только по ТЗ, или полный цикл. Все сами выбирают то, что им больше нравится и лучше получается (врятли любитель составлять ТЗ, но у которого это не выходит сумеет «продать» свое ТЗ другой команде).
Еще надо продумать момент, что иногда у команд разные спецификации. Скажем, одна — программисты, другая — дизайнеры/тестеры и т.д. В этом случае тоже надо продумать коммуникацию между ними.
. Т.е. дописали 1 число, но стерли 2. Итого всего чисел уменьшилось (как и промежутков).
1) (40!) Да, верно (Когда решал, думал, что придется вспоминать и другие признаки делимости ;))
5) (4х1+5х0) А как быть с тем, что количество чисел уменьшается (написали 1, стерли 2?). В итоге 1 число останется, значит все числа и равны между собой. (может, я задачу не так понял?)
Например, чтобы вместо
a = obj.getProp() писать a = obj.Prop, который в дальнейшем транслировался бы именно в getter?
P.S. Отписался в личку.
В реальности, чтобы такое заработало — надо просто взять и сделать ;) Да, рискованно; да, страшно, но без практического внедрения это все остается только идеями и далее ни куда не уходит…
Какие я вижу минусы:
1) Заказчик 1 — у него, соответственно, монополия на заказы… В принципе, решается введением еще нескольких начальников (заказчиков).
2) Есть возможность у исполнителя уйти на более интересный проект (мало ли что, такое запрещать нельзя, ведь насильно мил не будешь :)), в этом случае появляется опасность того, что ключевой разработчик просто уйдет.
3) А что в плане з/п? Если комбинировать — то откуда брать постоянную часть зарплаты, если команд разработки много, а заказов мало? «Нахлебников» терпеть особо не любят…
4) Санкции на невыполнение работы — не есть хорошо.
5) Кто будет устанавливать сроки? Если ты изначально неправильно оценил объем работ или заказ поменялся, то все летит кувырком…
6) Как и было сказано, нужно проработанное ТЗ, что значит, что его надо проработать. А кто этим занимается? Лучше всего, когда этим занимается именно тот человек, кто будет непосредственно реализовывать это все…
В принципе, список можно продолжать… Все это требует более глубокой проработки, но и пока не попробуешь на практике, не поймешь всех минусов, а часть может оказаться надуманной…
Еще про очки могу сказать, что они помогают восстановить зрение только до того уровня, который мы видим прищурившись (могу и ошибаться, но врач так рассказывал)…