На сцене появилась история и гражданские генералы? Это уже было, директора колхозов, рулящие дивизиями и не знавшие с какой стороны пуля из ствола вылетает. Правда потом супостат купался в Крыму, стоял на Волге и катался в Сокольниках на мотоциклах.
Ладно, я не любитель пустых споров, творческих успехов вам.
В армии отлично бы смотрелось — «офицеры не должны быть военными, пусть будут одни доверенные солдаты, которые не дадут другим недоверенным солдатам обмануть балбесов-командиров». Просто блеск
феерический бред и собрание комплексов и обид автора
— это я просто без комментариев оставлю. Увы. Далее, по сути
Где нормальные типы менеджеров? Которые изначально готовились как менеджеры, а не ломали карьеру, переходя из исполнителей в руководители?
А действительно, где? Где, как, кем осуществляется подготовка кадров на позиции менеджеров программных проектов? Было бы замечательно с ссылкой на учебный план и учебное заведение. Может я слона то не приметил, и все здорово в датском королевстве.
Но дежурный администратор правил файл шаблона в другом редакторе, который поместил этот символ в конец файла
То есть критично важный код пишут и тестируют одни и те же люди, а потом другие люди еще его правят? Блестяще организованный процесс обеспечения качества, есть чему поучиться.
Понятно почему у вас бажные скрипты выполняются в бажном кастомном интерпретаторе, а потом все валиться.
Потом, пункт два:
Одноклассники состоят из примерно 150 подсистем (различные базы данных, серверы бизнес-логики, кэши, графы, фронтэнды, системы конфигурации и т.д.). И работоспособность практически каждой подсистемы зависит от доступности других.
Вы считаете это хорошей архитектурой?
В извлечении уроков я не увидел ничего, касающегося пересмотра архитектурных подходов.
P.S. Избавьте от этих вопросов для самопроверки, в данной ситуации на двоешников похожи больше вы.
Мне к сожалению реально лень в тысячу первый раз устраивать дебаты на эту тему, если считаете что полноценный инженер возможен без профильного высшего образования — всякое мнение имеет право быть. Наверное имеет.
Автор, импонирует Ваша история. Надеюсь не произошло «головокружение от успехов» и в Ваших планах есть получение высшего профильного образования, то бишь переход из состояния талантливого самоучки в состояние дипломированного специалиста.
Раз разработчикам так нужен Agile, то пусть используют Agile у себя внутри, мы даже оставим итерации и аналитики будут передавать разработчикам не всё ТЗ целиком, а небольшие порции требований, скорректированные с учетом последней демонстрации тестовой версии программы заказчику;
Разработчикам уносить ноги надо из таких «молодых и небольших компаний». Тут по одному абзацу понятен уровень развития менеджмента.
Относительно новая специальность, готовящая по сути менеджеров программного продукта. Этот специалист смотрит поверх задач разработки, управляет требованиями, функционалом, версиями, командами разработки. На первых курсах вы изучите технологии программирования и, возможно, пару языков, но дальше в учебном плане будет всё больше про управление разработкой ПО. Начинать карьеру можно как Junior Developer, но вместо дальнейшего апгрейда до Middle вы станете менеджером проекта.
Автор, ну не надо писать ахинею и вводить детей и прочих абитуриентов в заблуждение.
Тут идет жонглирование двумя понятиями — стратегией продаж и качеством продукта. Покупая авто даже в самой убогой комплектации, покупатель никогда не получит машину с разной компрессией в цилиндрах, отваливающимся глушителем и дырявым бензобаком. Маркетинговая стратегия в компании автора видимо такая — срубим заказ, выставя зараннее зауженные сроки реализации, загоним разработчиков в перегорание и хронический стресс, поставим клиенту говно, потом под соусом «доработки под заказчика» будем допиливать то, что валится слишком явно. А потом еще, на десерт, подпишем клиента на поддержку продукта, потом что багов в таком говнософте предостаточно, и они будут периодически всплывать.
У меня нет конкретных мыслей как все правильно делать, если нет конкретной вводной.
Налаживание процесса даже в небольших командах — задача довольно трудоемкая я таящая в себе множество подводных камней.
В Вашей ситуации возможно есть смысл «схантить» менеджера из состоявшейся серьезной софтверной фирмы, который имеет реальный опыт оценки и распределения ресурсов, организации и налаживания взаимодействия группы (нескольких групп) разработчиков, контроля качества продукта, развертывания (поставки), и, самое главное, реальные проекты, «ушедшие» в продакшн.
Идеальный вариант, проектов схожей направленности и схожих масштабов.
Возможно ошибка, что Вы сделали ставку на людей из академической среды, плюс не имевших опыта конкретно в этом виде деятельности. Дьявол в мелочах, как известно H2O и H2SO4 отличаются только одним элементом. Самые лучшие практики, использованные не по назначению, разумеется могут дать противоположенный эффект, тут нет ничего удивительного.
-Участвовать в проведении научных исследований (экспериментов, наблюдений и количественных измерений) программных продуктов, проектов, процессов, методов и инструментов программной инженерии
-Заниматься построением моделей программных проектов и программных продуктов с использованием инструментальных средств компьютерного моделирования
-Составлять описания проводимых исследований, готовить данные для составления обзоров и отчетов
-Заниматься сбором и анализом требований заказчика к программному продукту
-Помогать заказчику в оценке и выборе вариантов программного обеспечения
-Участвовать в составлении коммерческого предложения заказчику, готовить презентации и согласовывать пакет договорных документов
-Проектировать компоненты программного продукта в объеме, необходимом для их конструирования в рамках поставленного задания
-Создавать компоненты программного обеспечения (кодирование, отладка, модульное и интеграционное тестирование)
-Выполнять измерения и рефакторинг кода в соответствии с планом
-Заниматься разработкой тестового окружения и созданием тестовых сценариев
-Разрабатывать и оформлять эскизную, техническую и рабочую проектную документацию
-Осваивать и применять средства автоматизированного проектирования, разработки, тестирования и сопровождения программного обеспечения
-Осваивать и применять методы и инструментальные средства управления инженерной деятельностью и процессами жизненного цикла программного обеспечения
-Осуществлять контроль, оценку и обеспечение качества программной продукции
-Обеспечивать соответствие разрабатываемого программного обеспечения и технической документации российским и международным стандартам, техническим условиям, нормативным документам и стандартам предприятия
-Участвовать в процессах разработки программного обеспечения
-Участвовать в создании технической документации по результатам выполнения работ
-Проводить обучение и аттестацию пользователей программных систем
-Участвовать в разработке методик обучения технического персонала и пособий по применению программных систем
-Участвовать в составлении технической документации (графиков работ, инструкций, планов, смет, заявок на материалы, оборудование, программное обеспечение)
-Планировать и координировать работу по настройке и сопровождению программного продукта
-Организовывать работу малых коллективов исполнителей программного проекта
-Вводить в эксплуатацию программное обеспечение (осуществлять инсталляцию, настраивать параметры, адаптировать, администрировать)
-Осуществлять профилактическое и корректирующее сопровождение программного продукта в процессе эксплуатации
-Обучать и консультировать пользователей по работе с программной системой
Чем быдлокодер, получившийся в результате неких «курсов», отличается от инженера по разработке ПО, можно попытаться понять например тут.
Ладно, я не любитель пустых споров, творческих успехов вам.
А действительно, где? Где, как, кем осуществляется подготовка кадров на позиции менеджеров программных проектов? Было бы замечательно с ссылкой на учебный план и учебное заведение. Может я слона то не приметил, и все здорово в датском королевстве.
То есть критично важный код пишут и тестируют одни и те же люди, а потом другие люди еще его правят? Блестяще организованный процесс обеспечения качества, есть чему поучиться.
Понятно почему у вас бажные скрипты выполняются в бажном кастомном интерпретаторе, а потом все валиться.
Потом, пункт два:
Вы считаете это хорошей архитектурой?
В извлечении уроков я не увидел ничего, касающегося пересмотра архитектурных подходов.
P.S. Избавьте от этих вопросов для самопроверки, в данной ситуации на двоешников похожи больше вы.
Разработчикам уносить ноги надо из таких «молодых и небольших компаний». Тут по одному абзацу понятен уровень развития менеджмента.
Автор, ну не надо писать ахинею и вводить детей и прочих абитуриентов в заблуждение.
Браво, бис!
Он прав, это будет провоцировать сode smells в неумелых ручках.
А код и приложение — это какие- то ортогональные вещи? После этой фразы читал уже по инерции. Не статья, а манифест говнокодера.
Во-вторых, по сайту, в качестве контруктивной критики — очень не понравился шрифт в навбаре, раскалывает все впечатление от дизайна страницы, ИМХО.
Налаживание процесса даже в небольших командах — задача довольно трудоемкая я таящая в себе множество подводных камней.
В Вашей ситуации возможно есть смысл «схантить» менеджера из состоявшейся серьезной софтверной фирмы, который имеет реальный опыт оценки и распределения ресурсов, организации и налаживания взаимодействия группы (нескольких групп) разработчиков, контроля качества продукта, развертывания (поставки), и, самое главное, реальные проекты, «ушедшие» в продакшн.
Идеальный вариант, проектов схожей направленности и схожих масштабов.
Возможно ошибка, что Вы сделали ставку на людей из академической среды, плюс не имевших опыта конкретно в этом виде деятельности. Дьявол в мелочах, как известно H2O и H2SO4 отличаются только одним элементом. Самые лучшие практики, использованные не по назначению, разумеется могут дать противоположенный эффект, тут нет ничего удивительного.
Чем быдлокодер, получившийся в результате неких «курсов», отличается от инженера по разработке ПО, можно попытаться понять например тут.