Могу предположить, что эти оценки Вы делаете для фиксированной команды и для более-менее похожих проектов. Угадал? Ну либо Вы реально гений планирования, что в риски закладываете 10-25%, и у Вас все сходится. В таком случае «респект и уважуха», как говорится. Но мне все же кажется, что тут без особых условий не обошлось. Уж слишком красиво получается. :)
И что, правда так работает? Я бы еще на 2-3 умножил. Или вот как г-н rusec ниже предложил, но с его подходом есть неслабый шанс получить за такие оценки в бубен от начальства.
ну так а если бы дырки продавались в магазине на вес, переносились в обычном кармане и «вставлялись» в стену как-то очень просто, например, приклеиванием, Вы бы покупали именно дырки, а не перфоратор, правда?
Хороший ВУЗ даёт прежде всего отличные условия для того, чтобы получать знания, опыт, связи и вырасти как личность.
Хороший вуз прежде всего — это правильный networking. У нас, конечно, нет Лиги Плюща, где студент может написать CEO компании из Fortune 500 и получить личную встречу или стажировку просто на основании того, что этот CEO заканчивал тот же университет. Но все равно когда человек узнает, что ты «тоже мат-мех заканчивал», можно сразу получить несколько бесплатных очков благосклонности в свою пользу. Ну и контакты с преподавателями, многие из которых не последние люди в индустрии, и одногруппниками, которые станут такими людьми лет через 10 — вот, чем одни вузы отличаются от других. Есть, конечно, редкие исключения, но в остальном набор и содержание предметов в топовых вузах не настолько критично разнятся.
Я помню, как эти картинки Якобсон показывал на SEAFOOD 2010, это все казалось довольно утопично уже тогда. Под громкие имена они набрали сотни полторы supporter'ов, встретились несколько раз, и дело заглохло. Последние документы на сайте датируются 2013 годом, примерно тогда же Мейер перестал себя публично с этим проектом ассоциировать. Не знаю, может когда-то вся эта область знаний уложится в голове кого-нибудь одного, и ему удастся сделать единый мета-метод программной инженерии, но пока это все напоминает попытку формализовать необъятное. Кому оно пригодится в реальной жизни с реальным бюджетом, коллективом, задачами и проблемами?
На мой взгляд, предлагаемый ими подход — это крайность. И если они каким-то чудом доведут ее до чего-то применимого на практике, получится то же, что с UML — в реальной жизни из него используется лишь несколько «народных» диаграмм, а остальные находят свое применение лишь у фанатиков и в книжках про этот язык. Ну а попытка сделать из него язык программирования — это отдельная история (тоже, кстати, с треском провалившаяся).
Так я и говорю, что я знаю очень многих людей, которых не затрагивает «обслуживание интересов серости». Сидят тихо мирно пишут драйвера или алгоритмы обработки видео. Для них что изменилось?
Так Вы говорите — программирование нынче уже не то, теперь все формочки рисуют и кнопочки перекрашивают. А я Вам говорю, что тот хардкор, про который Вы писали с уважением, точно так же востребован, как и 50 лет назад. И учить таких специалистов тоже нужно.
Ну Вы так говорите, как будто задача программиста — это только писать код. Вот тут в конце поста есть ссылка с примерным списком компетенций, предъявляемых к профессии «программист».
Их труд просто стал немного другим. И для других задач требуются другие люди с другими навыками. Никто же не заставляет хардкорного линукс-кернел программиста формочки верстать. А если заставляют, ему несложно найти другое место, где будут ценить его навыки. Низкоуровневое программирование встроенных устройств, системное программирование, математические расчеты и все остальные «элитные» задачи то никуда не делись и не денутся никогда.
Почему-то об оценке сроков никогда не говорят, когда обучают программированию.
Ну потому что пошла дурная традиция считать, что задача программиста только в том, чтобы программировать. А если заменить «программиста», на «разработчика ПО», тогда сразу начинают казаться актуальными и курсы по работе с требованиями, основам управления проектами, тайм-менеджменту, и все остальные полезные штуки. Вот только где найти хороших преподавателей с такими навыками в ПТУ или каком-нибудь аграрном университете, кои сейчас массово «готовят» «программистов».
Так если Вы хотите сказать, что в настоящее время создаются продукты, подверженные creeping featurism, так я всецело согласен. Вот только это вряд ли вина программистов, это вопросы к маркетологам, аналитикам, менеджерам и прочим людям, которые собирают, анализируют и формулируют требования к разрабатываемому софту. Именно поэтому я вон выше и предлагал при обучении программистов заставлять их задумываться о том, как их поделки будут использоваться дальше, а не просто кодировать то, что было сказано.
Под легким я понимаю ровно то, о чем писал автор заметки — сопровождение, поддержка, улучшение и т.п.
Так ну вот я Вам описал схематично, как происходила разработка и поддержка обсчета сложных математических задач. Вы всерьез считаете, что это проще, чем посидеть и переверстать GUI под новый экран или сделать отображение каких-нибудь свистелок в 3D?
Поэтому программист никогда не сможет сказать «я завершил работу над программой», даже если сама по себе задача действительно решена и удовлетворяет заказчика.
А это не программисту решать. Работа над программой (видимо, все же «продуктом» в данном случае) будет завершена, когда slakeholder'ы (как это сказать по-русски?) решат, что она удовлетворяет основным бизнес-целям и требованиям. Ну а как они эти бизнес-цели определят, это уже другой вопрос.
Дырку в стене можно просверлить любым перфоратором, однако их продается over дофига моделей и каждая находит покупателя.
Ну так давайте представим воображаемый мир, где можно купить дырок в стене. Человек стоит перед выбором — купить набор дырок (по аналогии, например, с винтами разных размером и диаметров) и устанавливать их в стены при необходимости, или купить инструмент, который надо будет таскать за собой и использовать каждый раз, когда возникнет потребность в дырке. И что он выберет, зависит от того, какую свою проблему он хочет решить. Если ему нравится строительство, он, конечно, купит перфоратор, но просто потому, что не «получить удовлетворение от строительства» в магазине не продается.
Смысл цитаты был в том, что никто никогда не покупает что-то ради самой вещи, вещи выбирают, чтобы минимизировать усилия и ресурсы для достижения какого-то результата. Тот же айфон 6 покупается не для того, чтобы получить какую-то дополнительную функциональность, это уже давно элемент имиджа и статусности. Перефразируя цитату, «если бы человек мог напрямую купить +100 понтов, он бы напрямую купил понты и не покупал у вас айфон». Так что айфон — такой же инструмент для достижения цели, как и все остальное. В эту же категорию попадают и другие вещи, которые покупают просто потому, что могут.
А что Вы понимаете под «легким»? Я бы не сказал, что программирование для вычисления параметров ядерной реакции было простым и доступным. Чтобы получить результат обсчета, нужно было написать дифур, запрограммировать его, а потом долго разбираться, где ошибка, в уравнении, коде или железе. Почитайте Turing's Cathedral, например, там это все в деталях описывается. Сейчас это сделает на матлабе любой студент-первокурсник, несоизмеримо быстрее и качественнее.
Я так понимаю, Ваше основное недовольство в том, что элитарное становится массовым. Ну так подобные метаморфозы происходили, происходят и будут происходить всегда почти во всех областях техники. Технологии как бы для того и создаются, чтобы упрощать жизнь людям. А Ваши аргументы звучат примерно так, что вот автопоилка на ферме слишком сложная, вот когда все руками делалось, тогда люди знали толк в коровах.
Сегодня я вообще не понимаю, как можно стать программистом — даже если понимать под «стать» всего-навсего изучение какого-либо языка с наиболее популярным фреймворком для него, то к моменту завершения изучения появляется новая версия языка и две или три версии фрейморка
Эм, нет. Пролистайте, например, вот это. Не идеальный документ, но там кроме собственно написания кода к программисту предъявляется еще десятка два компетенций.
Да понятно, что задача программиста — писать хороший код в нужные сроки и т.п., но программист, который не думает о том, что находится за пределами его зоны ответственности, так и будет всю жизнь писать код по спецификации сверху. Мне кажется, при обучении программистов их нужно обязательно приучать к тому, зачем нужен их код, и как он будет использоваться.
Ну надо понимать, что для этого надо обладать серьезной внутренней дисциплиной, это работает не всегда и сразу оно так получаться не будет. Иначе бы у студентов дипломные проекты, а у аспирантов диссертации придумывались за игрой в доту. Я так понимаю, данная статья все же больше общеобразовательная для новичков.
Программа это то, что преобразует исходные данные в результат.
Я бы сказал, что программа — это то, что решает проблему своего пользователя, человека или другой программы. Как писал Котлер, «Человек, который покупает у вас перфоратор — на самом деле покупает не перфоратор, а дырку в стене в нужном для него месте и в удобное для него время». Можно написать идеальную и никому не нужную программу программу. Соответственно, в условия я бы добаил еще ожидания пользователей и корректность поставленной задачи этим ожиданиям. Зачастую про пользователей программисты и думать не думают (простите за каламбур), и в итоге наши устройства заполнены приложениями, несущими боль и страдания.
Хороший вуз прежде всего — это правильный networking. У нас, конечно, нет Лиги Плюща, где студент может написать CEO компании из Fortune 500 и получить личную встречу или стажировку просто на основании того, что этот CEO заканчивал тот же университет. Но все равно когда человек узнает, что ты «тоже мат-мех заканчивал», можно сразу получить несколько бесплатных очков благосклонности в свою пользу. Ну и контакты с преподавателями, многие из которых не последние люди в индустрии, и одногруппниками, которые станут такими людьми лет через 10 — вот, чем одни вузы отличаются от других. Есть, конечно, редкие исключения, но в остальном набор и содержание предметов в топовых вузах не настолько критично разнятся.
сумма всех этих часов == срок разработки?
На мой взгляд, предлагаемый ими подход — это крайность. И если они каким-то чудом доведут ее до чего-то применимого на практике, получится то же, что с UML — в реальной жизни из него используется лишь несколько «народных» диаграмм, а остальные находят свое применение лишь у фанатиков и в книжках про этот язык. Ну а попытка сделать из него язык программирования — это отдельная история (тоже, кстати, с треском провалившаяся).
Недостаток опыта решения подобных задач/планирования/оценки рисков? Ну и традиционный программистский оптимизм, видимо :)
Ну потому что пошла дурная традиция считать, что задача программиста только в том, чтобы программировать. А если заменить «программиста», на «разработчика ПО», тогда сразу начинают казаться актуальными и курсы по работе с требованиями, основам управления проектами, тайм-менеджменту, и все остальные полезные штуки. Вот только где найти хороших преподавателей с такими навыками в ПТУ или каком-нибудь аграрном университете, кои сейчас массово «готовят» «программистов».
Так ну вот я Вам описал схематично, как происходила разработка и поддержка обсчета сложных математических задач. Вы всерьез считаете, что это проще, чем посидеть и переверстать GUI под новый экран или сделать отображение каких-нибудь свистелок в 3D?
А это не программисту решать. Работа над программой (видимо, все же «продуктом» в данном случае) будет завершена, когда slakeholder'ы (как это сказать по-русски?) решат, что она удовлетворяет основным бизнес-целям и требованиям. Ну а как они эти бизнес-цели определят, это уже другой вопрос.
Ну так давайте представим воображаемый мир, где можно купить дырок в стене. Человек стоит перед выбором — купить набор дырок (по аналогии, например, с винтами разных размером и диаметров) и устанавливать их в стены при необходимости, или купить инструмент, который надо будет таскать за собой и использовать каждый раз, когда возникнет потребность в дырке. И что он выберет, зависит от того, какую свою проблему он хочет решить. Если ему нравится строительство, он, конечно, купит перфоратор, но просто потому, что не «получить удовлетворение от строительства» в магазине не продается.
Смысл цитаты был в том, что никто никогда не покупает что-то ради самой вещи, вещи выбирают, чтобы минимизировать усилия и ресурсы для достижения какого-то результата. Тот же айфон 6 покупается не для того, чтобы получить какую-то дополнительную функциональность, это уже давно элемент имиджа и статусности. Перефразируя цитату, «если бы человек мог напрямую купить +100 понтов, он бы напрямую купил понты и не покупал у вас айфон». Так что айфон — такой же инструмент для достижения цели, как и все остальное. В эту же категорию попадают и другие вещи, которые покупают просто потому, что могут.
Я так понимаю, Ваше основное недовольство в том, что элитарное становится массовым. Ну так подобные метаморфозы происходили, происходят и будут происходить всегда почти во всех областях техники. Технологии как бы для того и создаются, чтобы упрощать жизнь людям. А Ваши аргументы звучат примерно так, что вот автопоилка на ферме слишком сложная, вот когда все руками делалось, тогда люди знали толк в коровах.
Эм, нет. Пролистайте, например, вот это. Не идеальный документ, но там кроме собственно написания кода к программисту предъявляется еще десятка два компетенций.
Я бы сказал, что программа — это то, что решает проблему своего пользователя, человека или другой программы. Как писал Котлер, «Человек, который покупает у вас перфоратор — на самом деле покупает не перфоратор, а дырку в стене в нужном для него месте и в удобное для него время». Можно написать идеальную и никому не нужную программу программу. Соответственно, в условия я бы добаил еще ожидания пользователей и корректность поставленной задачи этим ожиданиям. Зачастую про пользователей программисты и думать не думают (простите за каламбур), и в итоге наши устройства заполнены приложениями, несущими боль и страдания.