Планирование деятельности в образовании
Длительное планирование - это, обычно, забота не программиста, а руководителя проекта. Поэтому мне кажется, что подобные знания будут излишними.
Согласен, т.к. очень и очень многие требования - вытекают именно из разработки больших проектов и командной работы.
Да, снесли в программирование. Жалко, конечно, остаться не понятым, нужно было яснее писать сразу.
Вообще речь шла не только о программистах, а о тех же математиках, о любой деятельности. Точно так же любому математику приходится составлять планы по доказательству, потом успешно их проваливать.
Конечно, это не так сильно проявляется, потому что в математике постановка глобальных задач не развита. По моему опыту - доказывают, что можно доказать, остальное бросают. Такие же примеры необходимости составления планов можно найти даже в работе дворника.
Вообще речь шла не только о программистах, а о тех же математиках, о любой деятельности. Точно так же любому математику приходится составлять планы по доказательству, потом успешно их проваливать.
Конечно, это не так сильно проявляется, потому что в математике постановка глобальных задач не развита. По моему опыту - доказывают, что можно доказать, остальное бросают. Такие же примеры необходимости составления планов можно найти даже в работе дворника.
+1
Но не стоит планировать ради планирования, иногда имеет смысл уволить половину программистов и разхдрвинуть сроки. 10000 программистов не смогут написать мегапроект за 1 день, и планирование в таком случае может занять десятилетия.
Еще добавлю, что надо учить детей сразу разбивать сложную задачу на несколько простых. Если человек научится это делать -- он станет хорошим руководителем проектов.
Но не стоит планировать ради планирования, иногда имеет смысл уволить половину программистов и разхдрвинуть сроки. 10000 программистов не смогут написать мегапроект за 1 день, и планирование в таком случае может занять десятилетия.
Еще добавлю, что надо учить детей сразу разбивать сложную задачу на несколько простых. Если человек научится это делать -- он станет хорошим руководителем проектов.
// Еще добавлю, что надо учить детей сразу разбивать сложную задачу на несколько простых. Если человек научится это делать -- он станет хорошим руководителем проектов.
Да уж, аналитический подход практически универсален.
Да уж, аналитический подход практически универсален.
Такой подход, как показывает жизнь, не верен в корне. НеобходимоЖизнь показывает как раз наоборот....
обучение планированию на самых ранних этапах деятельности. В любом
случае, этот предмет не менее важен, чем философия.
вот ты говоришь проект а на реализацию год...
А теперь просто посмотри, сколько версий винды вышло за последние 10 лет - сейчас - уже 7я для радового пользователя... А это знаит, что проект, занимающий год реализации по прошествию года просто будет никому не нужен по причине морального устаревания....
Так что тебя не зря пугают годичные и более проекты, ибо они как правило - нерентабельны и бесполезны....
(под годичными проектами я не говорю об операционках и о поддержке программного продукта, я говорю именно о написании ОДНОГО программного продукта в течении большого (год, два, пол-года) промежутка времени)
ИМХО - программный продукт можно считать успешным, если период его морального устаревания раз в 10 больше чем процесс его разработки...
насколько я понимаю бизнес-процессы в айти, крупный программный проект идет год. Или два года. Просто потому, что организационно работа фирмы устроена годичными циклами. Бухгалтерия, отпуска, набор массовых и переманивание конкретных сотрудников, выставки - все устроено так, чтобы большинство проектов фирмы выполнялось за год.
проект - это от придумал, до получил денег....
а я говорю о НАПИСАНИИ программного продукта...
Если писать прогу год, то это может либо быть операционка, либо собственный узкоспециализированный инструмент локализованный под свои нужды без каких либо аналогов в мире IT и без конкурнетных компаний производителей....
Ну а в такие проекты большинство наших выученных программеров не опадут никогда... так то и учить их писать годовые проекты тоже не надо...
Надо учить думать и решать малые одзадачи чего-то более общего...
Принцип "разделяй и властвуй" актуален и сегодня... и через несколько сот лет...
а я говорю о НАПИСАНИИ программного продукта...
Если писать прогу год, то это может либо быть операционка, либо собственный узкоспециализированный инструмент локализованный под свои нужды без каких либо аналогов в мире IT и без конкурнетных компаний производителей....
Ну а в такие проекты большинство наших выученных программеров не опадут никогда... так то и учить их писать годовые проекты тоже не надо...
Надо учить думать и решать малые одзадачи чего-то более общего...
Принцип "разделяй и властвуй" актуален и сегодня... и через несколько сот лет...
> Если писать прогу год,
Ты забываешь о том, что вторая версия программы - это обычно первая версия программы + рюшечки.
т.е. тот код, которые написал в первой версии - тебе придется еще поддерживать и с ним работать - очень долгое время.
Возьмем: Rar, bat, far, TC, LA и т.д.
Все они живут - лет по 5, если не больше.
Поэтому если ты даже проповедуешь принцип: каждый месяц новая версия - все равно тебе придется 5 лет поддерживать тот код, который ты написал в первой версии.
Ты забываешь о том, что вторая версия программы - это обычно первая версия программы + рюшечки.
т.е. тот код, которые написал в первой версии - тебе придется еще поддерживать и с ним работать - очень долгое время.
Возьмем: Rar, bat, far, TC, LA и т.д.
Все они живут - лет по 5, если не больше.
Поэтому если ты даже проповедуешь принцип: каждый месяц новая версия - все равно тебе придется 5 лет поддерживать тот код, который ты написал в первой версии.
наверно у нас с тобой происходит подмена понятий,..
Я говорю о том, что писать проект год - это бесцельная трата времени, ибо он морально устареет...
Но тем не менее все равно надо поддерживать ее, даже если она моральноустарела...НО время поддержки абсолютно никоим образом не может быть задействовано в нашем разговоре, т.к. разговор о НАПИСАНИИ!
а потому - твои аргументы не к месту...
те же последующие версии - если ее писать месц а потом год поддерживать и потом писать еще месяц следующую -это выгодно и праильно, а если ее писать год, а потом не менять 10 лет - ну ты сам знаешь, что произошло за последние 10 лет и куда ушли все программки под дос....
Я говорю о том, что писать проект год - это бесцельная трата времени, ибо он морально устареет...
Но тем не менее все равно надо поддерживать ее, даже если она моральноустарела...НО время поддержки абсолютно никоим образом не может быть задействовано в нашем разговоре, т.к. разговор о НАПИСАНИИ!
а потому - твои аргументы не к месту...
те же последующие версии - если ее писать месц а потом год поддерживать и потом писать еще месяц следующую -это выгодно и праильно, а если ее писать год, а потом не менять 10 лет - ну ты сам знаешь, что произошло за последние 10 лет и куда ушли все программки под дос....
все дело в правильном маркетинге 
ты спрашиваешь, куда ушли программы под дос - советую поинтересоваться судьбой программы НДФЛ
ты спрашиваешь, куда ушли программы под дос - советую поинтересоваться судьбой программы НДФЛ
я не спрашиваю, а привожу пример....
подтверждающий тот факт, что надо уметь прогать частные решения, а не учится прогать бесполезное пол-жизни....
А то получится как с этой гамой... ну которая про чернобыль...
Пока писали одну часть - вторая устарела (движок приклось переписывать, а уже и конкуренты свои продукты выпустили.. И если в идеале это был прорыв, то сейчас выйти бы им на ноль - и то хорошо....
подтверждающий тот факт, что надо уметь прогать частные решения, а не учится прогать бесполезное пол-жизни....
А то получится как с этой гамой... ну которая про чернобыль...
Пока писали одну часть - вторая устарела (движок приклось переписывать, а уже и конкуренты свои продукты выпустили.. И если в идеале это был прорыв, то сейчас выйти бы им на ноль - и то хорошо....
> НО время поддержки абсолютно никоим образом не может быть задействовано в нашем разговоре, т.к. разговор о НАПИСАНИИ!
> а потому - твои аргументы не к месту...
Совсем не согласен.
Т.к. пока ты будешь тратить время на поддержку плохо написанного кода от первой версии,
конкуренты выпустят уже вторую версию.
> а потому - твои аргументы не к месту...
Совсем не согласен.
Т.к. пока ты будешь тратить время на поддержку плохо написанного кода от первой версии,
конкуренты выпустят уже вторую версию.
нет, ну опять ты про поддержку...
говорю же тебе, что речь не о поддержке, а о времени чистого кодинга...
говорю же тебе, что речь не о поддержке, а о времени чистого кодинга...
поддержка - это и есть время чистого кодинга.
Что такое поддержка - это, например, чтобы старый код работал на новой версии ОС, чтобы в старом коде не было старых багов, чтобы в этом старом коде были такие-то новые фичи и т.д.
и все это чистый кодинг.
Что такое поддержка - это, например, чтобы старый код работал на новой версии ОС, чтобы в старом коде не было старых багов, чтобы в этом старом коде были такие-то новые фичи и т.д.
и все это чистый кодинг.
время чистого кодинга - это реализация ТЗ в виде программного продукта.
поддержка - это устранение ошибок, обнаруженых в процессе эксплуатации, причем не выходящих за рамки ТЗ.
НО, поддержка осуществляется после завершения той фазы работ над проектом, которую мы обсуждаем. Т.е. после внедрения в жизнь этого проекта...
и я говорю о том, что если от начала реализации проекта до момента перехода в стадию поддержки готового продукта проходит год (пол-года, два года то это нерентабельный проект. и никому не нужный.....
Пример уже приводил....
поддержка - это устранение ошибок, обнаруженых в процессе эксплуатации, причем не выходящих за рамки ТЗ.
НО, поддержка осуществляется после завершения той фазы работ над проектом, которую мы обсуждаем. Т.е. после внедрения в жизнь этого проекта...
и я говорю о том, что если от начала реализации проекта до момента перехода в стадию поддержки готового продукта проходит год (пол-года, два года то это нерентабельный проект. и никому не нужный.....
Пример уже приводил....
>никому не нужный
нужный клиенту, вбухавшему нехилые бабки
нужный клиенту, вбухавшему нехилые бабки
> и я говорю о том, что если от начала реализации проекта до момента перехода в стадию поддержки готового продукта проходит год (пол-года, два года то это нерентабельный проект. и никому не нужный.....
Еще раз повторю, у нас есть проект, который живет на рынке 5 лет, каждую новую версию мы выпускаем допустим раз в три месяца.
внимание, вопрос: надо ли планировать, и если надо то как и когда развитие данного продукта?
Еще раз повторю, у нас есть проект, который живет на рынке 5 лет, каждую новую версию мы выпускаем допустим раз в три месяца.
внимание, вопрос: надо ли планировать, и если надо то как и когда развитие данного продукта?
а я то думал что мы об этом:
значит максимальный срок кодинга Вашего продукта - 3 месяца... А не год!
Подумай, как бы жила ваша компания, если бы вы тратили на разработку новогй версии не 3 месяца а год? а два ?
Написание небольших программ всегда было относительно легким делом, еслиа оказывается - вы выпускаете продукт раз в три месяца....
человек может справиться с этим за неделю, то трудно ожидать сложности.
Другое дело с проектами, требующими хотя бы года планирования и работы.
Такая сложность всегда меня пугала.
значит максимальный срок кодинга Вашего продукта - 3 месяца... А не год!
Подумай, как бы жила ваша компания, если бы вы тратили на разработку новогй версии не 3 месяца а год? а два ?
так что не надо доказывать прописные истины, что учится и совершенствоваться можно до бесконечности...это и так известно.ю...
Еще раз: не важно как часто мы выпускаем версии, а важно - сколько времени продукт живет и поддерживается.
ты так и не ответил на вопрос:
сколько времени и когда мы планируем - если мы хотим, чтобы наш продукт жил как минимум 5-10 лет?
ты так и не ответил на вопрос:
сколько времени и когда мы планируем - если мы хотим, чтобы наш продукт жил как минимум 5-10 лет?
Взять, например, любой большой продукт - например, word - нормальное время разработки с нуля несколько лет,
но при этом используя тот же xp-подход, версии можно выпускать хоть каждый день.
но при этом используя тот же xp-подход, версии можно выпускать хоть каждый день.
сколько времени и когда мы планируем - если мы хотим, чтобы наш продукт жил как минимум 5-10 лет?столько сколько надо перед началом разработки кодинга....
И если спланировали хорошо, то можно разделить кодинг на паралельные потоки и написать тот же ворд с нуля....
А если галимо придумано, то так и бедете каждые три месяца новую версию, каждую неделю - новый патч......
Ну-ну, винда конечно может и бесполезна, но вроде рентабельна. А также солярка и прочее и прочее и прочее. Извини, но ты прогнал и сам этого похоже не заметил.Такой подход, как показывает жизнь, не верен в корне. НеобходимоЖизнь показывает как раз наоборот....
обучение планированию на самых ранних этапах деятельности. В любом
случае, этот предмет не менее важен, чем философия.
вот ты говоришь проект а на реализацию год...
А теперь просто посмотри, сколько версий винды вышло за последние 10 лет - сейчас - уже 7я для радового пользователя... А это знаит, что проект, занимающий год реализации по прошествию года просто будет никому не нужен по причине морального устаревания....
Так что тебя не зря пугают годичные и более проекты, ибо они как правило - нерентабельны и бесполезны....
под годичными проектами я не говорю об операционках и о поддержке программного продукта, я говорю именно о написании ОДНОГО программного продукта в течении большого (год, два, пол-года) промежутка времениоффтоп - ты думаешь каждая очередная винда с нуля пишется что ли?
E.g. проект, в котором сам работаю, существует уже почти 7 лет, в нём многие миллионы строк кода. Я знаю людей, которые работают над проектами, которые стартовали 20 лет назад. Никакого отношения к "оперционкам и поддержке программного продукта" они не имеют. А теперь подумай сколько десятков тысяч людей были за их существование вовлечены хотя бы в один подобный проект, и многомиллиардное бабло таких проектов не в последнюю очередь зависит от строгого планирования, и каждый строго должен следовать плану проекта.
ИМХО - программный продукт можно считать успешным, если период его морального устаревания раз в 10 больше чем процесс его разработки...Тебя послушать, так самый удачный коммерческий программный продукт это
main{
printf("Hello World!\n");
} Да чувак, похоже ты пока только на таком уровне программируешь
Я говорю о том, что писать проект год - это бесцельная трата времени, ибо он морально устареет...Я говорю о том, что есть проекты, которые невозможно написать в 3 месяца, или сколько ты там считаешь нужным, и они нисколько не устаревают, а лишь становятся всё более и более потребными, и их дальнейшее девелоперство это необходимость(если конечно хочется заработать не 100 000$ на проекте, а например 10 000 000 000$ или больше).
можно такой нескромный вопрос, а много ли ты знаешь одиночных продуктов, которые приносят десять миллиардов долларов?
И если спланировали хорошо, то можно разделить кодинг на паралельные потоки и написать тот же ворд с нуля....Это вполне пиздато спланировано, если возможен вариант выпускать "каждые три месяца новую версию, каждую неделю - новый патч". При галимом планировании такие маленькие сроки просто нереальны
А если галимо придумано, то так и бедете каждые три месяца новую версию, каждую неделю - новый патч
Дам скормный ответ - на пальцах не пересчитать, причём если начать считать вслух, то уверен ты будешь все их знать.
например? ни одного не знаю. Назови 7, для определенности, хоть узнаю монстров
Скажу ключевые слова - Windows, Office, Linux, Solaris, Cisco, IBM, LG, Nokia, Intel.
Виндуз стоит 100 баксов в среднем. Ты хочешь сказать, что было продано сто миллионов копий виндуз?
то же самое касается офиса и соляриса
линукс - это не проект, это десятки проектов (кстати, виндузов и офисов - тоже десяток и к нему применим тот же вопрос
под сиской ты подразумеваешь иос? не знаю, сколько он стоит, и сколько экземпляров продано, поинтересуюсь на фирме
ибм - это, пардон, что? вся линейка рэшионалов?
лж, нокия, интел? я тебе могу сказать, сколько стоит интелу его огромный полностью проприетарный почти не воруемый продукт диалоджик. Версии SR5.1.1FP1 и SR6.0 продаются по 500-1000уе, за все время не было продано даже десяти тысяч копий. Возможно, даже тысячи не продали.
то же самое касается офиса и соляриса
линукс - это не проект, это десятки проектов (кстати, виндузов и офисов - тоже десяток и к нему применим тот же вопрос
под сиской ты подразумеваешь иос? не знаю, сколько он стоит, и сколько экземпляров продано, поинтересуюсь на фирме
ибм - это, пардон, что? вся линейка рэшионалов?
лж, нокия, интел? я тебе могу сказать, сколько стоит интелу его огромный полностью проприетарный почти не воруемый продукт диалоджик. Версии SR5.1.1FP1 и SR6.0 продаются по 500-1000уе, за все время не было продано даже десяти тысяч копий. Возможно, даже тысячи не продали.
Во-первых правильно меня поправил - дурная привычка называть сумму продаж суммой заработка, сразу поправляюсь.
б) Уверен, что было продано намного больше
Тоже касается Оффиса и Соляриса(его конечно было продано меньше, потому что его не покупают люди, его покупают корпорации, покупают вместе с суппортом, и он на-а-амного дороже чем 100$)
Виндуз стоит 100 баксов в среднем. Ты хочешь сказать, что было продано сто миллионов копий виндуз?а) Она стоит намного дороже.
б) Уверен, что было продано намного больше
Тоже касается Оффиса и Соляриса(его конечно было продано меньше, потому что его не покупают люди, его покупают корпорации, покупают вместе с суппортом, и он на-а-амного дороже чем 100$)
линукс - это не проект, это десятки проектов (кстати, виндузов и офисов - тоже десяток)Я говорил о ключевых словах, а не о проектах. И на линуксе IBM и сотоварищи заработали дохуя. В частности косвенным образом - например по пункту за счёт повышения количества людей, знющих никсы, и соответственно понижения за эти _необходимые_ знания зарплаты. И тд.
ибм - это, пардон, что?ибм по секрету - это вообще _ВСЁ_. И _ВСЁ_ что есть, связано с IBM.
я тебе могу сказать, сколько стоит интелу его огромный полностью проприетарный почти не воруемый продукт диалоджик.Ты лучше скажи сколько стоит написание всемозможных дров, оптимизаций и тд под x386 линейку. Ты знаешь, что лишь с итаниума действительно можно говорить о начале другого проекта, а до этого проект вполне может быть назван одним проектом, использующим уверен (конечно не могу утверждать) один код и условную компиляцию?
Ты говоришь о тысячах баксов, но ещё раз обращу твоё внимание - такие суммы для людей, а качественно большие - для продаж корпорациям. Виндовс у тебя на компьютере и виндовс где-нибудь в конторе Воrland - это очень разные виндовс, хотя обе (например) ХР.
> Виндуз стоит 100 баксов в среднем. Ты хочешь сказать, что было продано сто миллионов копий виндуз?
windows - даже если брать только, начиная с 95 - на рынке уже 10 лет.
раз в три года windows надо обновлять
получается 10 млн. продаж в год или 30 млн. человек купили
т.к. windows стоит обычно и дома, и на работе - можно еще на 1.5 разделить
получается 20 млн.
если взять США + ЕС: то получается довольно скромно, если брать на единицу населения.
windows - даже если брать только, начиная с 95 - на рынке уже 10 лет.
раз в три года windows надо обновлять
получается 10 млн. продаж в год или 30 млн. человек купили
т.к. windows стоит обычно и дома, и на работе - можно еще на 1.5 разделить
получается 20 млн.
если взять США + ЕС: то получается довольно скромно, если брать на единицу населения.
> можно такой нескромный вопрос, а много ли ты знаешь одиночных продуктов, которые приносят десять миллиардов долларов?
AFAIK, основные деньги делаются не на прямых продажах софта, а на его поддержке.
Посмотри тот же Oracle - у них фактически только один продукт - и челы, при этом, входят в 10 самых богатых (если не ошибаюсь).
AFAIK, основные деньги делаются не на прямых продажах софта, а на его поддержке.
Посмотри тот же Oracle - у них фактически только один продукт - и челы, при этом, входят в 10 самых богатых (если не ошибаюсь).
В ответ на:Херню ты сказал...
В ответ на:
Такой подход, как показывает жизнь, не верен в корне. Необходимо
обучение планированию на самых ранних этапах деятельности. В любом
случае, этот предмет не менее важен, чем философия.
Жизнь показывает как раз наоборот....
вот ты говоришь проект а на реализацию год...
А теперь просто посмотри, сколько версий винды вышло за последние 10 лет - сейчас - уже 7я для радового пользователя... А это знаит, что проект, занимающий год реализации по прошествию года просто будет никому не нужен по причине морального устаревания....
Так что тебя не зря пугают годичные и более проекты, ибо они как правило - нерентабельны и бесполезны....
Ну-ну, винда конечно может и бесполезна, но вроде рентабельна. А также солярка и прочее и прочее и прочее. Извини, но ты прогнал и сам этого похоже не заметил.
В ответ на:
под годичными проектами я не говорю об операционках и о поддержке программного продукта, я говорю именно о написании ОДНОГО программного продукта в течении большого (год, два, пол-года) промежутка времени
оффтоп - ты думаешь каждая очередная винда с нуля пишется что ли?
я же сказал, что оперционки и всякий стафф им подобный не считаем...
а ты мои слова под свою идею перекрутил...
а потом их еще и повторил и доказывать стал, что винда - рентабельный долгосрочный проект...
я же сказал, что оперционки и всякий стафф им подобный не считаем...Я же сказал, что есть куча проектов, не связанных с операционками. Пример (тот самый 20ти-летний) - написание программного продукта, который программму на любом из сотен диалектов Кобола (ты знаешь, что на Коболе написано почти 200 миллиардов строк кода, что более 80% бизнес-приложений написано на Коболе, и что Кобол - это говно, а не язык?) переводит во что-нибудь человеческое? Начиналось всё с перевода кода в С, потом в С++, теперь в Java. Но проект-то один, везде надо парсить код, строить дерево разбора, переводить во что-то универсальное, что уже можно перевести во что угодно. Ну и, это как, всякий стафф, да? Подобных примеров - кучи, просто их можно либо знать, либо не знать.
а их "либо незнаю", ибо мне это нах не нужно в жизни...
И тебе это нах не нужно... просто ты где то услышал, и теперь приводишь в качестве аргумента...
А я реально смотрю на вещи...
А реальность такова, что большинство школьников и студентов, которые ботают программинг в школе/универе никогда не бедет участвовать в 20ти летних проектах...
И знаие работы в таких проектах им тоже нах не надо....
А вот писать быстро маленькие приложения - это всегда полезно...
Ну а кому понадобится - тот проботает и 100летние проекты....
И тебе это нах не нужно... просто ты где то услышал, и теперь приводишь в качестве аргумента...
А я реально смотрю на вещи...
А реальность такова, что большинство школьников и студентов, которые ботают программинг в школе/универе никогда не бедет участвовать в 20ти летних проектах...
И знаие работы в таких проектах им тоже нах не надо....
А вот писать быстро маленькие приложения - это всегда полезно...
Ну а кому понадобится - тот проботает и 100летние проекты....
Бывшая однофакультетчица училась в США в ихней аспере. Так там на этом "team spirit" все помешаны были (это было не только в программировании, но и матем. задачи, и др. дисциплины требовалось иногда решать группой). В результате часто сводилось к тому, что один-два чела из группы делали все быстрее, и потом тратилось время, чтобы втолковать другим. Часто такая "групповая работа" вырождалась в пустую формальность - члены группы находились в разных зданиях, и просто чтоб не ходить туда-сюда реально все равно делалось по отдельности.
По-хорошему, такое обучение работе командой очень трудно организовать, и польза, чаще всего, очень сомнительна.
По-хорошему, такое обучение работе командой очень трудно организовать, и польза, чаще всего, очень сомнительна.
> Посмотри тот же Oracle - у них фактически только один продукт - и челы, при этом, входят в 10 самых богатых (если не ошибаюсь).
Оракл очень нехило и на продаже лицензий зарабатывает, как мне кажется. Видел недавно квотацию на проект, там отношение цены железа к цене Оракла, работающего на этом железе, было 5:2 примерно.
Оракл очень нехило и на продаже лицензий зарабатывает, как мне кажется. Видел недавно квотацию на проект, там отношение цены железа к цене Оракла, работающего на этом железе, было 5:2 примерно.
> А вот писать быстро маленькие приложения - это всегда полезно...
Быстро маленькие приложения пишут миллионы и миллионы леммингов: индусы, китайцы, не говоря уж про всех остальных. А вот грамотно реализовать большой проект могут уже немногие, и эти немногие зарабатывают много денег.
Быстро маленькие приложения пишут миллионы и миллионы леммингов: индусы, китайцы, не говоря уж про всех остальных. А вот грамотно реализовать большой проект могут уже немногие, и эти немногие зарабатывают много денег.
Интересно, а примеры заданий есть?
Не так уж это должно быть страшно, в Mifical Man Month тоже описывается, что основную работу делает один, остальные помогают. Естественная организация группы.
Не так уж это должно быть страшно, в Mifical Man Month тоже описывается, что основную работу делает один, остальные помогают. Естественная организация группы.
И тебе это нах не нужно... просто ты где то услышал, и теперь приводишь в качестве аргумента...Не, чувак, только тебе нах не нужно, а мне это нужно, конечно я лишь в маленькой американской корпорации скромно работаю кодером, но всё же... Вот щас думаю - либо через год идти в Sun, либо года через 2-3 в Intel. Ты бы сам-то куда пошёл?
\PS Модерам - вынесете в оффтоп как относящееся к писькам
в Интел я бы вообще не пошел. Пообщавшись с подразделением Диаложик, я представляю, насколько коряво и погано они пишут софт. Причем, не потому, что у них плохие программеры, а потому, что процесс никак (или очень плохо) не систематизирован.
Кстати, и получают они не особо много. Я имею в виду руководителя отдела программеров и саппортеров по всей EMEA. Около 4000-5000 евро в месяц, налоги съедают больше половины. Итого 2000.
Кстати, и получают они не особо много. Я имею в виду руководителя отдела программеров и саппортеров по всей EMEA. Около 4000-5000 евро в месяц, налоги съедают больше половины. Итого 2000.
судя по предыдущему посту - я бы пошел в "планировщики" или "аналитики" того, что бы ты накодил в SUN...
А вообще - ты наверно целеустремленный человем и занимаешься тем, что тебе нравится...
Так что я пожалуй тоже займусь тем, что нравится мне... Поеду отдыхать на море....
А вообще - ты наверно целеустремленный человем и занимаешься тем, что тебе нравится...
Так что я пожалуй тоже займусь тем, что нравится мне... Поеду отдыхать на море....
Оставить комментарий
Viktori68
Сначала я не знал трудностей в программировании. Любая вычислительнаяпрограмма могла быть легко отлажена и начинала работать на радость мне и
преподавателям. В этом была, может быть, серьёзная ошибка представления
программирования для учащихся, тренирующихся на простых программах.
Оптимально, на мой взгляд, начинать обучение программированию с
участия в больших проектах. Это позволит начинающему сразу окунуться в
реальное программирование, ощутить на своем опыте те трудности, с
которыми ему придется столкнуться в дальнейшем.
Написание небольших программ всегда было относительно легким делом, если
человек может справиться с этим за неделю, то трудно ожидать сложности.
Другое дело с проектами, требующими хотя бы года планирования и работы.
Такая сложность всегда меня пугала.
Возможно, отсутствие обучения планированию работ один из наиболее важных
недостатков системы теперешнего образования в школе и в университете.
Подавляющее большинство заданий краткосрочны и не учитывают специфику
долгосрочной деятельности. Если планирование и осуществляется, то только
не учениками. Вместо этого учитель разрабатывает задания и порядок их
осуществления.
Такой подход, как показывает жизнь, не верен в корне. Необходимо
обучение планированию на самых ранних этапах деятельности. В любом
случае, этот предмет не менее важен, чем философия. Вместо трех курсовых
работ за все время обучения в университете необходимо выполнять
тридцать, причем сразу несколько в одно и тоже время. Работы также
обязательно должны быть совместными, то есть выполняться в группе.
Такое обучение может серьезно повысить уровень подготовки специалиста к
любой трудовой деятельности.
Вот так. Хочется почитать комментарии.