По моему скромному опыту скорее всего проблема в том что ТЗ в принципе не было. Или существовало виде формулировки:"Хочу электронную систему оплаты проезда по дорогам и чтобы работало." В компании сели подумали, прикинули риски с таким ТЗ, что разброс от сайта визитки с прикрученными базами, до нейросетей с распознаванием образов и номеров под любой регион включая всех приезжих. Вот отсюда и получили сумму, добавьте сюда внушительный пакет документации как по гос заказу и саппорт и сумма уже не будет казаться такой большой. А если тут еще и площадку в дата-центре надо поставить то может еще и доплатить нужно будет.
Вопрос в защите интересов работодателя. На это и надо делать упор, т.е. чтобы у работодателя возникли вопросы, нужно ему наступить где-то в конкретно его бизнесе. Если перейти программировать тракторы которые будут продаваться там же где продаются тракторы бывшего работодателя — это проблема, если рынки сбыта разные проблемы не будет, потому что доказать ущерб будет невозможно. Кроме того, нужно смотреть на юрисдикцию договора. В крайнем случае можно релокейтнуться на годик в другой регион или страну пока не истечет срок действия договоров.
Менторство — это не мокание лицом в плохой код. Только у меня появился вопрос, а почему этот "крутой" программист не давал джуну на ревью свой код? Все люди учаться на примерах. И показывать надо не только как делать не надо, но и как делать надо, в том числе на примере своего "идеального" кода.
Я то думал, тут учат робомобили друг с другом общаться, а не с пешеходами. Вот это реально бы помогло. Обмен информацией по ходу движения — "хочу обгонять, ок я не тороплюсь, на встречной никого". Вот это был бы прорыв.
Лучше опцию иметь, чем не иметь. Silver bullet никто не обещал, но если даже нескольким людям это поможет спасти жизнь, будет уже круто. Разумеется, адекватный врач, по телемедецине не будет давать брать на себя ответственность. Он может советовать, но не более. Принимать решение делать или нет может только кто-то на месте.
Господа, объясните пожалуйста в чем смысл минусования коментариев, которые были написаны раньше 1го, но по причине модерации провисели сутки и стали не первыми? Это такой стимул не писать вообще? Ведь возможности отозвать его или отредактировать нет.
Как по мне тут кроется краеугольный камень бизнеса, который сам же бизнес не понимает. Чем больше компания, тем больше издержки по ее управлению, больше информации которую нужно хранить и обрабатывать и нужны совсем другие методы и инструменты, тяжелые и неповоротливые. 1я ступень зрелости — стартап, тут достаточно карандаша и тетрадки чтобы делать все — вести бухгалтерию, документировать продукт, учитывать кто сколько отработал и т.д. А можно вообще в голове держать, если память хорошая. Дальше уже больше сотрудников памяти 1го человека не хватает, тетрадка заканчивается очень быстро и смотреть в нее уже нужно нескольким людям а физически она в одном месте, а нужна она в разных и одновременно. Вот тут подключают IT отдел, трекинговую систему свою Wiki, бухгалтерскую систему. Все это желательно бесплатное, и обычно гибкое, костыляется скриптами иногда падает, но ведь простой 3-5 человек из-за упавшей на час другой системы — это не так дорого. Растем дальше, у нас уже 50-100 человек, и тут уже IT отдел понимает, что в случае чего простой будет у 60-80 человек и систеа обросла костылями и падает чаще и 1 час такого простоя обходится в 1-2 тыс. долларов для компании. В месяц набегает 10-20 тысяч, вот IT это понимает, а бизнес — нет. Спрашивается почему??? Бизнес кричит хочу гибкость хочу плюшки. Расходы от простоя растут, IT изо дня в день бьются с одними и теми же проблемами, бонусов уже давно не видели, потому как этот бюджет съеден падающими сервисами и простоями. Но бизнес же хочем гибкости, а не вложений в стабильную работу. Мотивация падает ниже плинтуса и начинается самый веселый этап — "текучка". И тут понеслось, бизнес кричит хочу быстро, поэтому документации минимум. Старые люди и знания уходят, приходят новые, которым никто не может объяснить как это все работает их бросают на монстра из костылей и без документации и говорят "в бой". В результате этот костыльный мостр загибается под собсвенной тяжестью один раз упавши и не в силах больше подняться.
Господа "бизнес", я вас очень прошу почитайте PMBoK, 2ой этап зрелости компании — бюрократизация и документация, плюс стабилизация систем и стандартизация инструментов. Цель этого этапа ликвидировать критические точки, т.е. людей чей уход однозначно ведет к краху компании. Его нужно просто пережить, лучше помогите своей компании его пережить и выйти дальше в масштабируемость.
Аналитик в лучшем случае сможет преобразовать объяснения бизнеса в технически поставленную задачу. Прояснить связи между задачами и расставить технические зависимости сможет разве что аналитик с очень хорошим опытом в разработке.
Мне доводится весьма нередко после аналитиков, задавать уточняющие вопросы по Acceptance Criteria, выправлять критерии которые невозможно измерить, указывать что новая story конфликтует с другой иногда уже закрытой пару лет назад. Указывать что в коде присутсвуют workaround, которые когда-то задолго до подключения к проекту закостыляла другая команда, а новый функционал делает этот workaround в дальнейшем безсмысленным и неплохо бы добавить sub-task на рефакторинг с его удалением.
Короче говоря, в контексте Scrum, Lead оценивает постановку задачи в user story и помогает ее разбить на sub-tasks. При высоком уровне зрелости каждого члена команды разработчики/тестировщики, Lead может быть и не нужен. Но по-моему опыту и исследованию знакомого психолога, большинство програмистов интраверты и не любят общаться с не техническими людьми. Вот те немногие программисты экстраверты, которые находят контакты с менеждментом и отлично подходят на роль лида, и они общаются за своих колег которые не хотят/могут построить это общение продуктивно.
Поддерживаю, хочу только еще добавить, что далеко не каждый программист(даже senior) поговорив с "бизнесом" поймет задачу, важность и зачем она нужна бизнесу. TL должен кроме прочего выступать связующим звеном, которое сможет выслушать/вычитать "поток сознания" бизнеса(менеджеров), переварить это дело, разобрать как его лучше сделать или может вообще лучше не делать или поменять местами порядок выполнения задач, что сократит "критический путь" достижения цели и изложить уже в понятной техническим людям(разработчикам) форме. Грубо говоря он должен защищать команду от менеджеров и давать им комфортно работать и выступать переводчиком с бизнес языка на технический язык.
А как там с надежностью этих Б/У ступеней? В наш то век когда сделать новый экземпляр дешевле чем ремонтировать старый? Не будет ли дешевле производить новую ступень чем диагностировать старую разбираться что в ней требует ремонта/замены, выполнять работы, тестировать опять и запускать?
К сожалению с редакторами карт Quake и UT не сложилось. А вот за Blizzard'овскими провели много времени. Помню когда нашел программу запуска редактора уровней, вместо запуска игры был очень удивлен. А потом так затянуло, что даже не знаю на что больше времени потратил на игры или создание уровней.
Позволю себе несколько не согласиться с мнением автора, что "программист должен программировать и точка". Программировать и точка может может стажер или еловек оркестр который может сам сделать завершенный продукт. Во всех остальных случаях нужно коммуницировать с окружением, чтобы сообща решать задачи, чтобы не делать басню "Лебедь, рак и щука", да банально чтобы получить повышение. А при коммуникации, главное говорить на "одном языке" с общей системой терминов, поэтому даже программисту необходимо понимать остальных. Я за несколько лет насмотрелся на матерых технарей, которые не умеют доносить свои мысли до иностранных коллег, до менеджеров и т.д. Смотришь на них и печально становится, вроде идеальный программист, разбирается в предмете и продукте как архитектор. А из-за своего убеждения что программист должен программировать, а не заниматься всякой менеждерской ерундой типа митингов — так и сидит на одной должности без повышения лет 10-15. И ждет пока его заметят, подойдут похвалят и вручат билет в светлое будущее на блюдечке с золой каемочкой. Нет, в жизни так не работает. Даже если ты супер-пупер крутой программист и коммитишь патчи, например в ядро Linux, тебе придется еще быть очень красноречивым чтобы объяснить менеджеру, что в этом такого крутого и почему тебе надо больше денег, чем какому-нибудь другому сотруднику с которым он вместе играет в гольф.
Ну на сколько я понял суть статьи, в очередной раз вівели разницу между низкоуровневым и высокоуровневым языком. С — воплощает собой философию Unix/Linux, потому именно на нем много кода для них и написано. Одна задача — одна программа. С++ это уже все же "швейцарский нож". Все удобнее, все быстрее пишется, зачастую код еще оказывается более переносимый, есть готовые модули, но плата за это производительность. Да можно оптимизировать и добиться лучших результатов если поставтить цель, но в реальной жизни в 90% никто этого делать не будет. Мало кто выбирает язык программирования и пишет и использует его вразрез принятых в конкретном языке парадигм.
Поэтому язык нужно выбирать как раз из этих критериев в первую очередь. Нужно максимальное быстродействие, не нужна переносимость, нет необходимость в чрезвычайно сложных структурах данных и объектах, размер проекта и сроки не ужаты сверх меры в угоду менеджерских целей — можно делать на С. Если же сроки сжаты, колличество меньше, чем хотелось бы и охватить нужно область знаний большую чем вы детально понимаете, а также вы не хотите выжать максимум на каждой операции и вообще вы полагаете что для данного проекта необходимо в несколько раз больше людей/команд — быстрее будет сделать на С++.
Думаю в 17-19 веках влияние турецкого сказалось даже сильнее. Войны очень сильно поощряют изучение языка противника. На украинский язык влияние турецкий оказал не меньше, чем на русский из-за непосредственного соприкосновения. Также есть влияние немецкого, просочившееся через Австро-Венгрию. Польский также разумеется, хотя тот же польский — это ветка славянского на латинском алфавите.
С моей точки зрения школьной физики, энергия пули гаситься бронепластинами и трансформируется в тепловую, что приводит к изменению физических свойст материалов пули и бронепластины они становятся более пластичны. В результате получаем сплюснутую пулю и вмятину на пластине. Т.о. будет ли пластина пробита определяется ее способностью быстро перенять и рассеять энергию по всей площади не достигнув критического для материала локального повышения температуры в случае которого материал пластины станет достаточно эластичным для пробоя, а пуля сохранит еще необходимую для полета энергию. Поэтому материал пластины и важно подобрать не только сверх-прочным, но и достаточно сбалансированным для поглощения и рассеивания энергии пули, чтобы защитить тело не только от проникновения пули но и от ее энергии. Лучшая пробивающая способность винтовочной(остроконечной) пули обусловлена меньшей начальной площадью соприкосновения, а соответственно большему количеству тепловой энергии на единицу площади пластины.
PS Я не знаток бронежилетов, но на мой взгляд изспользование слоеных материалов может весьма этому поспособствовать, однако в свою очередь явно приведет к увеличению стоимости. Скорее всего современные модели как раз и спользуют несколько слоев, верхние для поглащения энергии и ее рассеивания, чтобы до пластин пуля уже доходила значительно утратив энергии.
Не спора для, а интереса ради — откуда такое заключение, если козаки лет 300 служили барьером для Москвы от Турецко-татарского Крыма? Я бы скорее сказал, что на русский в свое время оказали влияния голландский, немецкий и французский в зависимости от эпохи империи, кто был в фаворитах, и с кем воевали. Влияние это оказывалось в основном через двор и придворных, обитающих в Москве и Петербурге, южные регионы тогда были несколько изолированы от важных международных событий.
Пожалуй все таки несколько новее. Для меня он хоть и весьма похож на немецкий, но в нем все же ряд вещей довольно условно подчиняется правилам. То же произношение варьируется от региона к региону. А если говорить конкретно об отличиях от немецкого, то числительные все таки проще читать линейно и разделять пробелами, не нужно каждое существительное писать с заглавной буквы и т.д. Да с временами наворотили гораздо сильнее, хотя многие утверждают что в жизни достаточно тех же 4х что и в немецком.
По моему скромному опыту скорее всего проблема в том что ТЗ в принципе не было. Или существовало виде формулировки:"Хочу электронную систему оплаты проезда по дорогам и чтобы работало." В компании сели подумали, прикинули риски с таким ТЗ, что разброс от сайта визитки с прикрученными базами, до нейросетей с распознаванием образов и номеров под любой регион включая всех приезжих. Вот отсюда и получили сумму, добавьте сюда внушительный пакет документации как по гос заказу и саппорт и сумма уже не будет казаться такой большой. А если тут еще и площадку в дата-центре надо поставить то может еще и доплатить нужно будет.
Вопрос в защите интересов работодателя. На это и надо делать упор, т.е. чтобы у работодателя возникли вопросы, нужно ему наступить где-то в конкретно его бизнесе. Если перейти программировать тракторы которые будут продаваться там же где продаются тракторы бывшего работодателя — это проблема, если рынки сбыта разные проблемы не будет, потому что доказать ущерб будет невозможно. Кроме того, нужно смотреть на юрисдикцию договора. В крайнем случае можно релокейтнуться на годик в другой регион или страну пока не истечет срок действия договоров.
Менторство — это не мокание лицом в плохой код. Только у меня появился вопрос, а почему этот "крутой" программист не давал джуну на ревью свой код? Все люди учаться на примерах. И показывать надо не только как делать не надо, но и как делать надо, в том числе на примере своего "идеального" кода.
Я то думал, тут учат робомобили друг с другом общаться, а не с пешеходами. Вот это реально бы помогло. Обмен информацией по ходу движения — "хочу обгонять, ок я не тороплюсь, на встречной никого". Вот это был бы прорыв.
Как по мне тут кроется краеугольный камень бизнеса, который сам же бизнес не понимает. Чем больше компания, тем больше издержки по ее управлению, больше информации которую нужно хранить и обрабатывать и нужны совсем другие методы и инструменты, тяжелые и неповоротливые. 1я ступень зрелости — стартап, тут достаточно карандаша и тетрадки чтобы делать все — вести бухгалтерию, документировать продукт, учитывать кто сколько отработал и т.д. А можно вообще в голове держать, если память хорошая. Дальше уже больше сотрудников памяти 1го человека не хватает, тетрадка заканчивается очень быстро и смотреть в нее уже нужно нескольким людям а физически она в одном месте, а нужна она в разных и одновременно. Вот тут подключают IT отдел, трекинговую систему свою Wiki, бухгалтерскую систему. Все это желательно бесплатное, и обычно гибкое, костыляется скриптами иногда падает, но ведь простой 3-5 человек из-за упавшей на час другой системы — это не так дорого. Растем дальше, у нас уже 50-100 человек, и тут уже IT отдел понимает, что в случае чего простой будет у 60-80 человек и систеа обросла костылями и падает чаще и 1 час такого простоя обходится в 1-2 тыс. долларов для компании. В месяц набегает 10-20 тысяч, вот IT это понимает, а бизнес — нет. Спрашивается почему??? Бизнес кричит хочу гибкость хочу плюшки. Расходы от простоя растут, IT изо дня в день бьются с одними и теми же проблемами, бонусов уже давно не видели, потому как этот бюджет съеден падающими сервисами и простоями. Но бизнес же хочем гибкости, а не вложений в стабильную работу. Мотивация падает ниже плинтуса и начинается самый веселый этап — "текучка". И тут понеслось, бизнес кричит хочу быстро, поэтому документации минимум. Старые люди и знания уходят, приходят новые, которым никто не может объяснить как это все работает их бросают на монстра из костылей и без документации и говорят "в бой". В результате этот костыльный мостр загибается под собсвенной тяжестью один раз упавши и не в силах больше подняться.
Господа "бизнес", я вас очень прошу почитайте PMBoK, 2ой этап зрелости компании — бюрократизация и документация, плюс стабилизация систем и стандартизация инструментов. Цель этого этапа ликвидировать критические точки, т.е. людей чей уход однозначно ведет к краху компании. Его нужно просто пережить, лучше помогите своей компании его пережить и выйти дальше в масштабируемость.
Аналитик в лучшем случае сможет преобразовать объяснения бизнеса в технически поставленную задачу. Прояснить связи между задачами и расставить технические зависимости сможет разве что аналитик с очень хорошим опытом в разработке.
Мне доводится весьма нередко после аналитиков, задавать уточняющие вопросы по Acceptance Criteria, выправлять критерии которые невозможно измерить, указывать что новая story конфликтует с другой иногда уже закрытой пару лет назад. Указывать что в коде присутсвуют workaround, которые когда-то задолго до подключения к проекту закостыляла другая команда, а новый функционал делает этот workaround в дальнейшем безсмысленным и неплохо бы добавить sub-task на рефакторинг с его удалением.
Короче говоря, в контексте Scrum, Lead оценивает постановку задачи в user story и помогает ее разбить на sub-tasks. При высоком уровне зрелости каждого члена команды разработчики/тестировщики, Lead может быть и не нужен. Но по-моему опыту и исследованию знакомого психолога, большинство програмистов интраверты и не любят общаться с не техническими людьми. Вот те немногие программисты экстраверты, которые находят контакты с менеждментом и отлично подходят на роль лида, и они общаются за своих колег которые не хотят/могут построить это общение продуктивно.
Поддерживаю, хочу только еще добавить, что далеко не каждый программист(даже senior) поговорив с "бизнесом" поймет задачу, важность и зачем она нужна бизнесу. TL должен кроме прочего выступать связующим звеном, которое сможет выслушать/вычитать "поток сознания" бизнеса(менеджеров), переварить это дело, разобрать как его лучше сделать или может вообще лучше не делать или поменять местами порядок выполнения задач, что сократит "критический путь" достижения цели и изложить уже в понятной техническим людям(разработчикам) форме. Грубо говоря он должен защищать команду от менеджеров и давать им комфортно работать и выступать переводчиком с бизнес языка на технический язык.
Позволю себе несколько не согласиться с мнением автора, что "программист должен программировать и точка". Программировать и точка может может стажер или еловек оркестр который может сам сделать завершенный продукт. Во всех остальных случаях нужно коммуницировать с окружением, чтобы сообща решать задачи, чтобы не делать басню "Лебедь, рак и щука", да банально чтобы получить повышение. А при коммуникации, главное говорить на "одном языке" с общей системой терминов, поэтому даже программисту необходимо понимать остальных. Я за несколько лет насмотрелся на матерых технарей, которые не умеют доносить свои мысли до иностранных коллег, до менеджеров и т.д. Смотришь на них и печально становится, вроде идеальный программист, разбирается в предмете и продукте как архитектор. А из-за своего убеждения что программист должен программировать, а не заниматься всякой менеждерской ерундой типа митингов — так и сидит на одной должности без повышения лет 10-15. И ждет пока его заметят, подойдут похвалят и вручат билет в светлое будущее на блюдечке с золой каемочкой. Нет, в жизни так не работает. Даже если ты супер-пупер крутой программист и коммитишь патчи, например в ядро Linux, тебе придется еще быть очень красноречивым чтобы объяснить менеджеру, что в этом такого крутого и почему тебе надо больше денег, чем какому-нибудь другому сотруднику с которым он вместе играет в гольф.
Ну на сколько я понял суть статьи, в очередной раз вівели разницу между низкоуровневым и высокоуровневым языком. С — воплощает собой философию Unix/Linux, потому именно на нем много кода для них и написано. Одна задача — одна программа. С++ это уже все же "швейцарский нож". Все удобнее, все быстрее пишется, зачастую код еще оказывается более переносимый, есть готовые модули, но плата за это производительность. Да можно оптимизировать и добиться лучших результатов если поставтить цель, но в реальной жизни в 90% никто этого делать не будет. Мало кто выбирает язык программирования и пишет и использует его вразрез принятых в конкретном языке парадигм.
Поэтому язык нужно выбирать как раз из этих критериев в первую очередь. Нужно максимальное быстродействие, не нужна переносимость, нет необходимость в чрезвычайно сложных структурах данных и объектах, размер проекта и сроки не ужаты сверх меры в угоду менеджерских целей — можно делать на С. Если же сроки сжаты, колличество меньше, чем хотелось бы и охватить нужно область знаний большую чем вы детально понимаете, а также вы не хотите выжать максимум на каждой операции и вообще вы полагаете что для данного проекта необходимо в несколько раз больше людей/команд — быстрее будет сделать на С++.
Думаю в 17-19 веках влияние турецкого сказалось даже сильнее. Войны очень сильно поощряют изучение языка противника. На украинский язык влияние турецкий оказал не меньше, чем на русский из-за непосредственного соприкосновения. Также есть влияние немецкого, просочившееся через Австро-Венгрию. Польский также разумеется, хотя тот же польский — это ветка славянского на латинском алфавите.
PS Я не знаток бронежилетов, но на мой взгляд изспользование слоеных материалов может весьма этому поспособствовать, однако в свою очередь явно приведет к увеличению стоимости. Скорее всего современные модели как раз и спользуют несколько слоев, верхние для поглащения энергии и ее рассеивания, чтобы до пластин пуля уже доходила значительно утратив энергии.