Комментарии 73
Как PM с большим стажем, скажу вам, что п.п. 3 вполне достаточно. Есть такая заповедь ПМ — если цель постоянно меняется [в процессе работы], ее невозможно достигнуть.
В целом же порадовало.
В целом же порадовало.
Гарантированный способ не доделать проект — не начинать его вовсе.
Вместо этого надо обсуждать идеи, которые приходят в голову, бесконечно их обсасывать, с применением пунктов 4 и 5 Вашего списка. И все это — не приступая к действиям, также крайне важно сконцентрироваться на поиске будущих недостатков и проблем, с которыми мывозможно обязательно столкнемся, обязательно надо заметить, что аналоги уже имеются, так что какой смысл все это начинать…
Клинический случай, конечно, но и такое бывает.
Еще в плане кода можно добавить пункт касательно необузданного «технического долга»: на ранних стадиях развития проекта, когда нужно быстро запустить, разумный тех.долг — это разумно, но пускаться здесь в крайности — еще один полноценный пункт к Вашему списку.
Вместо этого надо обсуждать идеи, которые приходят в голову, бесконечно их обсасывать, с применением пунктов 4 и 5 Вашего списка. И все это — не приступая к действиям, также крайне важно сконцентрироваться на поиске будущих недостатков и проблем, с которыми мы
Клинический случай, конечно, но и такое бывает.
Еще в плане кода можно добавить пункт касательно необузданного «технического долга»: на ранних стадиях развития проекта, когда нужно быстро запустить, разумный тех.долг — это разумно, но пускаться здесь в крайности — еще один полноценный пункт к Вашему списку.
Странно, но, прочитав заголовок, я сперва было подумал, что пост будет о том, как успешно сдать недоделанный проект, и остаться в живых)
Наболело, да? :)
НЛО прилетело и опубликовало эту надпись здесь
Была же недавно серия постов про молчание
Тогда пункт и п.9. Встречал индивидуумов, которые не хотят делиться знаниями, как будто им доставляет удовольствие кичиться своими знаниями и корчить из себя всезнающего партизана. Пункты 9 и 10 отражают общую проблему межличностной коммуникации среди программистов. Профессиональное общение это один из эффективных способов повышение квалификации. Иногда бывает так, что один не знает как что-то сделать, а другой не понимает как этого можно не понимать. И только терпеливое общение друг с другом позволят решить проблему.
«10 способов как вьехать в дерева» не научат водить автомобиль.
У меня был художник, который по максимуму использовал пункт 11. Я его называл «жизненный ипохондрик». Хороший художник, только одно плохо — опускал командный дух все команде, внезапным заходом к программистам и криками «все пропало». Конечно проект завалили..((
Приковать за ногу к рабочему месту в противоположном конце коридора? :-)
Гнать в шею даже самого толкового сотрудника, если он разлагает коллектив своим неверием в успех дела!
на 1 и 2-ом пунктах я уже плакал ((…
Смотрю вы разработчик-идеалист. Я так понимаю вы из тех, которым надо дать как можно больше денег и не трогать, пока вы будете тихо, спокойно, правильно разрабатывать проект.
Только вы забываете что в жизни все постоянно меняется, ваш умно проработанный архитектурно проект может оказаться никому не нужным. Вы можете опоздать с его внедрением. Вы можете не найти понимающего инвестора и денег на грамотных разработчиков и пээмов у вас не будет. И так далее и так далее.
Я не знаю ни одного проекта, который бы строился в идеальных тепличных условиях и стал великим. Но я знаю массу проектов, которые были готовы к трудностям и переменам по ходу своего развития и сейчас зарабатывают уйму денег или по крайней мере успешно работают на рынке своих ниш.
Только вы забываете что в жизни все постоянно меняется, ваш умно проработанный архитектурно проект может оказаться никому не нужным. Вы можете опоздать с его внедрением. Вы можете не найти понимающего инвестора и денег на грамотных разработчиков и пээмов у вас не будет. И так далее и так далее.
Я не знаю ни одного проекта, который бы строился в идеальных тепличных условиях и стал великим. Но я знаю массу проектов, которые были готовы к трудностям и переменам по ходу своего развития и сейчас зарабатывают уйму денег или по крайней мере успешно работают на рынке своих ниш.
Много косяков в проекте наделал я сам, так что совсем не идеалист. Но оглянувшись назад хочется как-то подитожить и хотябы стараться испавиться в будущем.
Если Вы при строительстве четвертого этажа здания будете постоянно говорить: нет, я передумал, хочу 3 этажа, а через месяц, не, все таки давайте 5, то ничего из этого хорошего не выйдет, как бы строители ни были готовы к трудностям.
Естественно в статье все утрированно на столько, чтоб люди четко поняли что автор имеет ввиду, на самом деле все тоньше и специфичней.
Естественно в статье все утрированно на столько, чтоб люди четко поняли что автор имеет ввиду, на самом деле все тоньше и специфичней.
С таким подходом пишите ТЗ в течении 1-2 лет и создавайте ПО для военных, там нельзя ошибаться и вам дадут время посидеть и предварительно хорошо подумать, а потом не будут вас просить откланяться от первоначального плана.
В современном вебе при разработке крупных клиенско-ориентированных систем в спокойном ритме можно создавать только базовое ядро, а дальше надо слушать клиента и меняться-меняться-меняться постоянно подстраиваясь под потребности клиентов.
В современном вебе при разработке крупных клиенско-ориентированных систем в спокойном ритме можно создавать только базовое ядро, а дальше надо слушать клиента и меняться-меняться-меняться постоянно подстраиваясь под потребности клиентов.
«Создай deadlock своему проекту!» — Открой и долго-долго читай хабр(etc...) про то, как сделать проект
16) приходите все в разное время, ведь каждый должен работать в своем ритме! идеально, если разработчик и менеджер не пересекаются вообще
НЛО прилетело и опубликовало эту надпись здесь
э… а интуиции кого из новичков лучше довериться, если их несколько, и их интуиции говорят прямо противоположные вещи?
А занудой быть так не хочется! :)
Демократия, имхо, не рулит совершенно. На всех уровнях управления, всем менеджерам проще при четкой иерархии.
Другое дело, что на исполнительском уровне демократия создаёт общую позитивную атмосферу и повышает производительность, поэтому именно там всякими аджайлами её и эмулируют.
А выше исполнительского уровня — принятия решений. И если при принятии решений мы строим демократию и будем голосовать — получится первый пункт.
А занудой быть так не хочется! :)
Демократия, имхо, не рулит совершенно. На всех уровнях управления, всем менеджерам проще при четкой иерархии.
Другое дело, что на исполнительском уровне демократия создаёт общую позитивную атмосферу и повышает производительность, поэтому именно там всякими аджайлами её и эмулируют.
А выше исполнительского уровня — принятия решений. И если при принятии решений мы строим демократию и будем голосовать — получится первый пункт.
Прочитав, подумал — а вы не мой коллега? :)
Почаще меняйте разработчиков — новые люди — свежие силы.
Почаще следуйте веяниям ИТ-сферы и новым технологиям, и переводите недоделанный проект на новую версию фреймворка или языка программирования.
Почаще изобретайте велосипеды — своя кмс-ка, а то и самописная nosql-база станут значительным конкурентным преимуществом — ведь ваш проект независим от чужих наработок.
Деньги — пыль. Не следует думать о монетизации и востребованности функционала проекта до самого его развала.
Почаще следуйте веяниям ИТ-сферы и новым технологиям, и переводите недоделанный проект на новую версию фреймворка или языка программирования.
Почаще изобретайте велосипеды — своя кмс-ка, а то и самописная nosql-база станут значительным конкурентным преимуществом — ведь ваш проект независим от чужих наработок.
Деньги — пыль. Не следует думать о монетизации и востребованности функционала проекта до самого его развала.
16) на протяжении всего проекта три раза смените 90% состава команды.
Спасибо, забавно было почитать.
Забейте на систему управления проектом/багтрекер. Ставьте задачи в джаббере или в личной беседе по телефону. Меняйте приоритеты задач как минимум раз в день (это позволит разработчикам оставаться в тонусе). И да, не вздумайте планировать, планы — зло, внесите фактор неожиданности в рабочий процесс, — команда ведь любит сюрпризы.
Никогда, никогда не пишите комментарии к своему коду.
Удобный, красивый и понятный код — для неудачников и маменькиных сынков, никогда не пишите его.
После написания критически важных кусков кода (модули? Не смешите меня!) в подобном стиле — уйдите в другую компанию, этим вы обсепечите торможение в работе ваших преемников, что возымеет свой эффект.
Удобный, красивый и понятный код — для неудачников и маменькиных сынков, никогда не пишите его.
После написания критически важных кусков кода (модули? Не смешите меня!) в подобном стиле — уйдите в другую компанию, этим вы обсепечите торможение в работе ваших преемников, что возымеет свой эффект.
проекту очень помогает, когда все употребляют какой-то общий наркотик, например марихуану. Курите весь день, не употребляющих лучше не брать на работу вообще.
Резюмирую: «Как сделать свою работу плохо? Работайте плохо!»
Спасибо автору, очень полезная статья.
Спасибо автору, очень полезная статья.
Ха, актуально :)
Не расстраивайтесь, в геймдеве неудачных проектов намного больше, чем в других областях. Такая уж специфика.
Прекрасные советы от обратного. Буду сюда периодически отсылать тех, кто любит заниматься ерудной в команде.
думаю, что тем, кому действительно стоит это прочитать даже не заходят на хабр.
17) Болейте и заражайте звездной болезнью! Ведь не ровен час, когда надо будет так ярко светить на небосклоне, а работать… работать будут мексиканцы.
Видно, что советы «придумал» pm-практик, потому что любая методика в принципе позволяет элиминировать косяки во время проекта, если пытаться максимально придерживаться методики и рекоммендаций. Хотя для начинающих — просто супер статья, потому что написана доступным для понимания языком.
Никогда не делайте бэкапов (это ж сколько места будет пропадать под никому ненужными копиями проекта) и используйте самое свежее ПО, собранное собственноручно из альфа-репозиториев разработчиков (все остальное безнадежно устарело и уже никем не используется).
n) Система контроля версий — для неуверенных в себе.
n+1) Отводить время на рефакторинг и ревью кода — пустое занятие. Программисты всегда уверены в своем коде и пишут его идеально.
n+1) Отводить время на рефакторинг и ревью кода — пустое занятие. Программисты всегда уверены в своем коде и пишут его идеально.
Система контроля версий не плохая штука, помогает… Рефакторинг и кодревью использовать только в меру, не злоупотреблять. Рефакторинг не должен приводить к «Эффекту второй системы». Кодревью должно провеодиться часто для новых сотрудников и изредко для давно работающих, для того чтоб помочь увидеть того, что разработчик не заметил.
Этакие «Вредные советы» от мира IT :)
Чувствуется горький опыт автора. Когда начинаешь работу (молодым), с полным энтузиазмом, не обращаешь внимание на эти вещи. Но когда от «ударов об стену» начинают болеть голова, будешь оценивать такие советы. С автором полностью «не» согласен :)
Первый пункт про художника — тысячу раз да! Пишу как пострадавший художник :D
Статья запомниться, так как я пытался на каждое утвержление продумать «противоположно-правильное»))
20) В самом начале проекта, когда считаете финансовые затраты, что бы показать инвестору (спонсору) — никогда о себе не думайте. Вы робот, который может работать, без оплаты личных затрат, 25 часов в сутке, и у вас все должно получаться на 100%. А вот ко всем подрядчикам, кого вы наняли- должны относиться с трепетом. Достойная з/п, выходные, не «напрягать», если не успевают и.т.д И к инвестору (спонсору) относиться с пониманием- экономить его деньги (как минимум на себе), выполнять все его просьбы, радовать только хорошими результатами и как можно меньше брать денег на проект, если появяться доп расходы-о которых не было известно раньше. Сами думайте где денюжку взять!
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Советы, как успешно завалить проект