Comments 26
Глянул, не поможет это всё. У разводил это всё есть. Здравого смысла только в Jire нет, а так всё есть. Весь проект полностью состоит из воды. Нужно чтобы они все обсуждения вели строжайше в письменном виде на форумном движке. И туда же кидали документы. Чтобы понимать, кто и как мыслит.
Без тестировщиков - будут находиться баги (возможно это опечатка, хотя...)
Если честно, то вся статья - это информационный мусор, который не имеет ничего общего с реальностью.
Управление проектами - это отдельная дисциплина и ей надо обучаться. Прочтите хотя бы одну книгу, чтобы понимать, что такое проект, как им управлять и какие метрики использовать для определения его здоровья. Это будет намного полезнее, чем гордиться тем, что впустую потратили своё время на получение бакалаврской степени по Прикладной информатике и создали эту бездарную статью.
Чтобы юное дарование направить в правильное русло, подсказываю. Есть такое понятие, как "треугольник управления проектом", куда входят:
Стоимость проекта
Время выполнения проекта
Объём проекта
Весь проект крутится внутри этого треугольника.
Всё, что нужно, чтобы оценить, жив проект или нет, это узнать:
1. На какой стадии находится выполнение проекта, т.е. какой объём был уже сделан;
2. Сколько денег уже было на него потрачено.
3. Сколько времени прошло с начала проекта.
Это может сделать любой человек, например, держатель бюджета, заказчик проекта или тот, кому в принципе этот проект нужен. Полученных данных будет достаточно, чтобы решить, стоит ли продолжать проект, нужно ли увеличивать команду исполнителей или лучше просто разогнать старых исполнителей и закрыть проект.
Спасибо за ваше честное мнение! Понимаю вашу точку зрения и вижу ваше стремление к глубокому пониманию управления проектами. Согласна что это глубокая область, требующая серьезного подхода и обучения. Моя статья не претендует на исчерпывающее руководство, я стремлюсь поделиться персональным опытом, который может быть полезен начинающим специалистам.
Согласна с вами насчет треугольника управления проектом, это конечно важно.
В своей статье я скорее касалась других аспектов, акцентируясь на том как теоретические знания применяются на практике. Разумеется одной статьи недостаточно для глубокого погружения в тему, и саморазвитие всегда имеет место быть. Кстати, если у вас есть рекомендации относительно книг или других ресурсов на эту тему - буду благодарна за их предоставление!
Что касаемо моего образования - для меня это ценный фундамент для роста дальнейших знаний. Гордость за образование вовсе не исключает необходимости в дальнейшем самообразовании.
Еще раз спасибо за ваш комментарий, критика стимулирует нас к дальнейшему развитию!
Карго-культ .
Непонятно следующее - если хотя бы одного артефакта или хотя бы одной активности нет - всё, проект плох?
Женщина, если ты закадычных гкниальных друга клепают свой офигительный проект, то ни одной перечесленной херни Там не будет. Там не будет гит Фло, они будут пушить в прод и деплоить через командную строку.
Никаких тестов, никаких дизайнеров и прочих Аджай мастеров.
То что вы описали - жто требование к корпоративному програмированию. - апофеоз нудной айтишной бюрократии
Попытки систематизировать знания и найти универсальный подход к борьбе с неопределенностью всегда заслуживают внимания и уважения по крайней мере к самому устремлению.
Было бы здорово:
разобраться со значением слова "проект" и в каком ключе вы его употребляете в своей статье; очевидно, здесь применяется максимально широкое трактование, что в общем случае плохо и гарантирует непонимание со стороны слушателя и закипание головного мозга
"Управление проектами" != "Управление процессами" != "Управление командами" != "У нас есть колонки, по которым можно двигать таски" как уже выше заметили; было бы очень здорово всё называть своими именами
разобраться с терминами "SDLC", "методология", "идеология", "фреймворк", вернуться к табличке, в которой нам нужно выбрать между методологиями управления проектами ("методологиями разработки"?) Agile, Scrum, Lean и Waterwall и постараться не провалиться сквозь землю; набор заблуждений и неточностей распространенный, сильно переживать не стоит
очень спорно это всё... 20 лет в индустрии дали мне пройти полный цикл от искусства (когда ты ничего не понимаешь но делаешь программы) через индустриальный подход (когда ты всё понимаешь и делаешь всё по правилам как описано в этой статье) обратно к искусству (когда ты чувствуешь как правильно и делаешь красиво), и я могу сказать что бизнес, который всю эту мешпуху потребляет, даже не догадывается каких огромных денег и времени (а это тоже деньги) ему это стоит. один нормальный чувак может заменить всю эту команду из 10 лоботрясов и сделает всё лучше, быстрее и дешевле, просто потому что сэкономит на коммуникации, документация понадобится концептуальная потому что код соответствует индустриальным стандартам, задач формальных не будет потому что чувак тесно работает с бизнесом и знает предметную область примерно так же хорошо, дизайнер не нужен потому что можно скачать и допилить красивый шаблон, DevOps тоже не нужен потому что для одного слишком затратно по времени заниматься такой ерундой... и всё service-ready монолит который если надо можно масштабировать только когда нужно и после того как бизнес это реально окупит. смысл во всех этих формальных выкрутасах нужен только когда страдает содержание - мотивация бизнеса отличается от мотивации программиста. когда общая цель и программист мыслит бизнес-категориями это всё просто отнимает время. и тесты только там где может поломаться
А потом этот замечатальный человек попадает под автобус и выясняется что у него там вот такое исскуство https://pikabu.ru/story/chuzhoy_kod_5762938. И потом бизнес пытается реанимировать этот проект и идет искать тех, кто бы за него взялся.
соответствие отраслевым стандартам
концептуальные комментарии
отсутствие оверинжениринга
Ответ из комментов по вашей ссылке:
Ибо у нас для всего есть определенные стандарты и правила и даже стандарты для костылей.
Грубо говоря, толщина стенки емкости и материал выбирается по методичке, в соответствии с заранее созданными расчётами, а фундамент льется заданной толщины, сваи забиваются также, исходя из определенного расчетного нагрузочного минимума. То есть, кто-то конечно может построить дом на воздушной подушке и несущим плакатом пинк флойд на стене, но это только самострой незарегистрированный, в реальную эксплуатацию, костыли не принимают обычно.
Так вот хочу задать вопрос, почему в программировании так часто говорят о костылях, говнокоде, каких-то велосипедах изобретенных, неужели нет никакого стандарта кодостроения, приемки этого кода?
У нас есть Agile, неопределенность требований, сжатые сроки, прототипы идущие в бой, технический долг, какая-нибудь свежая технология которую хочется попробовать и проверенный микроскоп которым удобно забивать гвозди... и 120 тонный вентилятор с прошлой работы.
Я бы знаете как сформулировал: главное, что приводит проект к успеху или провалу - это квалификация исполнителей, включая руководителей тоже. И если она в наличии, то можно сделать успешный проект, не выполнив ни один из пунктов данного чеклиста. И наоборот. А чеклисты подобного типа - их цель в какой-то степени нивелировать наличие в команде и вокруг разных долбодятлов, чтобы они не сильно вредили, а то и приносили пользу. Корпоративное программирование, чтобы мы под этим не понимали - оно тоже существует, и тоже временами завершает проекты.
И еще - автор обманывает себя и нас, утверждая, что эти пункты обобщаются на другие типы проектов, не веб. Нет конечно, не обобщаются. Именно потому что существуют и проекты, реализуемые в одно лицо, безо всяких дизайнеров, фронтендеров, коучей и всей этой необязательной в общем случае команды. На легаси инструментах. Без гитфлоу, и прочего и прочего. И если один человек в состоянии проект удержать в голове, то такие проекты часто более успешны, чем сделанные "по канонам эджайла".
А по сути по-моему получилось практически один в один как у вас, только другими словами?
Если всегда делать все по обозначенной инструкции - то бизнес не получится. И платить вам за вашу экспертизу будет... нечем.
Веток может быть две. Пуш может быть сразу в мастер. Может не быть пул-реквестов. Есть, например, trunk based development.
Выбор версии технологий не всегда зависит от команды, часто она связана ограничениями, наложенными реализацией пакетных зависимостей.
Про аджайлы и прочие скрамы - один грамотно подготовленный сектант способен полностью парализовать доставку фич. Это будет очень гибко. Но совершенно бесполезно.
Если делать как гугл - гуглом не станешь. Прочитайте про культ карго.
Ну и на счёт любых моделей - модель - не равно явление. Это лишь его описание. И нельзя безапелляционно заявлять про модель, опуская границы применимости.
Как, например, классическая физика работает при скоростях много меньше скорости света и масштабах много больше размера атома. Если приближаться к - там уже релятивистская и квантовая физики соответственно.
Ваши формулировки вредны, если цель в том, чтобы работа коллектива была рентабельна при сохранении человеческого отношения к людям.
Начнём с хорошего. :-) Сам чек-лист полезный, если по уму разобрать каждый пункт, а не удостовериться, что оно просто есть.
По тексту - местами кажется неплохо (там где чисто про разработку, типа баттлов в MR и диаграммы классов), ибо я в этом не силён, а вот остальное...
Вы скорее всего непосредственно в разработке крутитесь и дальше только видели со стороны и возможно выцепили несколько слов/определений из статей (не факт, что грамотных), ибо в разрезах управления проектами, командами, процессами и прочим, что не связано напрямую с написанием кода, мягко говоря, "плывёте".
И отдельно не стоило начинать статью, надевая на себя корону бакалавра с 6-летним опытом в вэбе.
Чуть развернутее бы про методологии и фреймворки - как по мне, так очень вольное описание
Соответственно, команда тоже будет зависеть от методологии , не все участники команды могут быть полностью задействованы, (проджекта не может быть в скраме, например)
В целом, обзорная статья для новичков, есть потенциал развить это в серию более подробных статьей ?
Чек-лист: технический аудит IT проекта