Советы, как успешно завалить проект

    На Хабре много статей о завершённых проектах (стартапах), советов как стать успешным и как доделать игру. Мне, к сожалению, довелось поучаствовать и в нескольких незавершённых проектах.

    Так вот, советы как завалить проект:

    1) Если вам в проекте нужна графика, каждый человек в команде должен попробовать себя в роли художника. Если задание отдано одному художнику, всем обязательно нужно принимать участие в обсуждении результата, давать советы и вообще всячески помогать. Художнику при этом нужно постоянно перерисовывать и править, дабы угодить всем сразу. Вообще, демократия – лучший метод для решения всех задач в проекте.

    2) Концепт не нужен, зачем тратить время? Главное, начать как можно быстрей писать код, а идеи и концепт обязательно придут в пути. Кто быстрей начнёт программировать, сможет забронировать самые интересные задания.

    3) Очень важно менять существенные вещи примерно в середине проекта, а лучше несколько раз. Ведь нужно было срочно программировать, и выбрали не ту технологию, не тот способ, 3D графику вместо 2D.

    4) Тратьте больше времени на выдумывание и обсуждение названия ещё не сделанного проекта или вашей будущей фирмы. Как назовешь корабль, так он и поплывет! Важно заранее выбрать тип будущей организации, может, акционерное общество лучше ООО?

    5) Заранее думайте, как будут поделены будущие миллионы. Пригрозите самым нерадивым сотрудникам, что вместо $600k они получат только $200k.

    6) Спешить в проекте не стоит, ведь ещё вся жизнь впереди. Мы обязательно доделаем все 1000 проектов! Когда-нибудь…

    7) Вообще, почаще начинайте новые проекты, а старые аккуратно замораживайте. В новом проекте будет новая мотивация, новая идея, да и сделать его можно ой как быстро. Главное, новому научитесь, потом в старый проект переймёте (смотри пункт 6).

    8) После каждого проекта проводите долгий разбор полётов, выясняя, кто же главный герой, заваливший проект? Это хорошо мотивирует героев больше геройствовать в развале следующих проектов, в которые их надо обязательно брать. Ведь мы уже знаем, где наступить на старые грабли!

    9) Помогать друг другу в проекте не стоит, пускай каждый сам находит ответ в интернете. Так лучше запоминается.

    10) Говорить о своих проблемах тоже нужно поменьше, а вдруг кто-то захочет помочь или дать совет. Вообще, молчание – золото! Так можно скрыть, что для дальнейшей работы тебе чего-то не хватает, и тем самым успешно создать простой проекта. Весело, когда много людей ждут друг друга и не говорят об этом! Создай deadlock своему проекту!

    11) Самое главное — побольше ныть о том, как хорошо удаётся завалить проект, как успешно ничего не делается, и потом ещё почаще напоминать всем об этом. Чтобы закрепился дух геройского недоделывания и проваливания проектов.

    12) Работу лучше делать несколько раз, сначала как попало, потом, когда-нибудь, можно сделать, как надо.

    13) Если встретили чужой код, сразу бросайте работу, ведь разбираться в нём очень тяжело и есть отмазка ничего не делать. Если очень хочется работать дальше, можно всё переписать самому! Вообще, лучше писать свои функции и не смотреть, есть ли уже такие в проекте.

    14) Звать в проект нужно побольше друзей, не важно, подходят они в проект или нет. Если кто-то не хочет, нужно долго уговаривать, а потом обижаться, если не уговорил. В каждом проекте должна быть своя драма!

    15) Если в проекте новые люди, сразу позаботьтесь, чтобы ещё не выдуманную идею или концепт не украли! Всем ли можно доверять?

    Может, и у вас есть дельные советы, как недоделать проект?
    Ads
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More

    Comments 73

      +20
      Как PM с большим стажем, скажу вам, что п.п. 3 вполне достаточно. Есть такая заповедь ПМ — если цель постоянно меняется [в процессе работы], ее невозможно достигнуть.

      В целом же порадовало.
        0
        Очень понравилась фраза. Вы кого-то процитировали (себя?) или это «народная мудрость»?
          +1
          Это чья-то чужая мудрость. По-моему я столкнулся с ней где-то в учебниках/курсах по ПМ.
        +11
        Гарантированный способ не доделать проект — не начинать его вовсе.
        Вместо этого надо обсуждать идеи, которые приходят в голову, бесконечно их обсасывать, с применением пунктов 4 и 5 Вашего списка. И все это — не приступая к действиям, также крайне важно сконцентрироваться на поиске будущих недостатков и проблем, с которыми мы возможно обязательно столкнемся, обязательно надо заметить, что аналоги уже имеются, так что какой смысл все это начинать…
        Клинический случай, конечно, но и такое бывает.

        Еще в плане кода можно добавить пункт касательно необузданного «технического долга»: на ранних стадиях развития проекта, когда нужно быстро запустить, разумный тех.долг — это разумно, но пускаться здесь в крайности — еще один полноценный пункт к Вашему списку.
          +4
          да да — эдакая коллективная ментальная мастурбация. Встретились, обсудили, пофантазировали и разошлись.
            +3
            При этом главное каждому подписать не разглашение/авторство — а то не дай бог продадут :)
              0
              А потом, когда что-то подобное увидеть в реализации-ходить с грустным и обиженным видом, что идею твою-украли!)
          +3
          Странно, но, прочитав заголовок, я сперва было подумал, что пост будет о том, как успешно сдать недоделанный проект, и остаться в живых)
            0
            Спасибо, заменил на: «Советы, как успешно завалить проект».
            +6
            Наболело, да? :)
              +2
              Очень :(.
                0
                +10 в гору
            • UFO just landed and posted this here
                +1
                Была же недавно серия постов про молчание
                  0
                  Не зря сказано:
                  Молчание — золото.
                    0
                    та… дорого обходится
                      0
                      И такое есть. Чо это мы все об грусном ;)
                  +1
                  Тогда пункт и п.9. Встречал индивидуумов, которые не хотят делиться знаниями, как будто им доставляет удовольствие кичиться своими знаниями и корчить из себя всезнающего партизана. Пункты 9 и 10 отражают общую проблему межличностной коммуникации среди программистов. Профессиональное общение это один из эффективных способов повышение квалификации. Иногда бывает так, что один не знает как что-то сделать, а другой не понимает как этого можно не понимать. И только терпеливое общение друг с другом позволят решить проблему.
                  +2
                  «10 способов как вьехать в дерева» не научат водить автомобиль.
                    +4
                    В том то и дело, что это самый действенный способ
                      +2
                      С автомобилем, лучше практикой =)
                      А если серьезно, то если изложить самые частые ошибки начинающего автолюбителя в подобной форме, то это авось бы и помогло кому то, чему то научиться)
                      +1
                      У меня был художник, который по максимуму использовал пункт 11. Я его называл «жизненный ипохондрик». Хороший художник, только одно плохо — опускал командный дух все команде, внезапным заходом к программистам и криками «все пропало». Конечно проект завалили..((
                        +3
                        Приковать за ногу к рабочему месту в противоположном конце коридора? :-)
                          +1
                          нет, он бы оттуда кричал))
                          +2
                          Гнать в шею даже самого толкового сотрудника, если он разлагает коллектив своим неверием в успех дела!
                            0
                            Сначала, я его заставил работать удаленно, чтоб он не влиял негативно на командный дух, потом совсем расстались и команду пришлось переформировать.

                            Вообще после это ситуации оценил значение поговорки «паршивая овца все стадо портит»
                              +1
                              А если это начальство — тоже выгнать? :)
                                +1
                                Если начальство — подыскивать другую работу и при первой возможности самому оттуда сваливать. =)
                                Все равно, с не верящим в успех компании начальником — любое дело обречено на провал.
                            0
                            на 1 и 2-ом пунктах я уже плакал ((…
                              +4
                              Смотрю вы разработчик-идеалист. Я так понимаю вы из тех, которым надо дать как можно больше денег и не трогать, пока вы будете тихо, спокойно, правильно разрабатывать проект.

                              Только вы забываете что в жизни все постоянно меняется, ваш умно проработанный архитектурно проект может оказаться никому не нужным. Вы можете опоздать с его внедрением. Вы можете не найти понимающего инвестора и денег на грамотных разработчиков и пээмов у вас не будет. И так далее и так далее.

                              Я не знаю ни одного проекта, который бы строился в идеальных тепличных условиях и стал великим. Но я знаю массу проектов, которые были готовы к трудностям и переменам по ходу своего развития и сейчас зарабатывают уйму денег или по крайней мере успешно работают на рынке своих ниш.
                                +3
                                Много косяков в проекте наделал я сам, так что совсем не идеалист. Но оглянувшись назад хочется как-то подитожить и хотябы стараться испавиться в будущем.
                                  0
                                  Вам большой плюс, что признаете свои ошибки, а не прикидываетесь Д'Артаньяном обвиняя всех и вся вокруг.
                                  +1
                                  Если Вы при строительстве четвертого этажа здания будете постоянно говорить: нет, я передумал, хочу 3 этажа, а через месяц, не, все таки давайте 5, то ничего из этого хорошего не выйдет, как бы строители ни были готовы к трудностям.
                                  Естественно в статье все утрированно на столько, чтоб люди четко поняли что автор имеет ввиду, на самом деле все тоньше и специфичней.
                                    0
                                    С таким подходом пишите ТЗ в течении 1-2 лет и создавайте ПО для военных, там нельзя ошибаться и вам дадут время посидеть и предварительно хорошо подумать, а потом не будут вас просить откланяться от первоначального плана.

                                    В современном вебе при разработке крупных клиенско-ориентированных систем в спокойном ритме можно создавать только базовое ядро, а дальше надо слушать клиента и меняться-меняться-меняться постоянно подстраиваясь под потребности клиентов.
                                      0
                                      Я же говорю: автор в топике утрирует, не нужно преувеличивать, и так понятно что изменчивое тз влияет на сроки, не стоит придираться только к этому пункту, да, он один из основных, но не единственный.
                                  +13
                                  «Создай deadlock своему проекту!» — Открой и долго-долго читай хабр(etc...) про то, как сделать проект
                                    +13
                                    16) приходите все в разное время, ведь каждый должен работать в своем ритме! идеально, если разработчик и менеджер не пересекаются вообще
                                      0
                                      Иногда актуально, когда менеджер «руками водитель».
                                    • UFO just landed and posted this here
                                        +2
                                        э… а интуиции кого из новичков лучше довериться, если их несколько, и их интуиции говорят прямо противоположные вещи?
                                        А занудой быть так не хочется! :)

                                        Демократия, имхо, не рулит совершенно. На всех уровнях управления, всем менеджерам проще при четкой иерархии.
                                        Другое дело, что на исполнительском уровне демократия создаёт общую позитивную атмосферу и повышает производительность, поэтому именно там всякими аджайлами её и эмулируют.

                                        А выше исполнительского уровня — принятия решений. И если при принятии решений мы строим демократию и будем голосовать — получится первый пункт.
                                        • UFO just landed and posted this here
                                        +1
                                        Прочитав, подумал — а вы не мой коллега? :)
                                          +14
                                          Почаще меняйте разработчиков — новые люди — свежие силы.
                                          Почаще следуйте веяниям ИТ-сферы и новым технологиям, и переводите недоделанный проект на новую версию фреймворка или языка программирования.
                                          Почаще изобретайте велосипеды — своя кмс-ка, а то и самописная nosql-база станут значительным конкурентным преимуществом — ведь ваш проект независим от чужих наработок.
                                          Деньги — пыль. Не следует думать о монетизации и востребованности функционала проекта до самого его развала.
                                          • UFO just landed and posted this here
                                            • UFO just landed and posted this here
                                              0
                                              Почаще следуйте веяниям ИТ-сферы и новым технологиям, и переводите недоделанный проект на новую версию фреймворка или языка программирования.

                                              Может у вас есть шанс стать DNF, и все таки выпуститься через N лет :)
                                                0
                                                Ага. Эдакий Duke Nukem Forever :-)
                                              +3
                                              16) на протяжении всего проекта три раза смените 90% состава команды.
                                                0
                                                Спасибо, забавно было почитать.
                                                  +9
                                                  Забейте на систему управления проектом/багтрекер. Ставьте задачи в джаббере или в личной беседе по телефону. Меняйте приоритеты задач как минимум раз в день (это позволит разработчикам оставаться в тонусе). И да, не вздумайте планировать, планы — зло, внесите фактор неожиданности в рабочий процесс, — команда ведь любит сюрпризы.
                                                    +1
                                                    Очень похоже на организацию труда, в моей организации. :)
                                                      +2
                                                      Задачи необходимо распределять по телефону часа в 3 ночи, потому что услышанная перед сном/во время сна информация запоминается и усваивается намного лучше.
                                                      0
                                                      Никогда, никогда не пишите комментарии к своему коду.
                                                      Удобный, красивый и понятный код — для неудачников и маменькиных сынков, никогда не пишите его.
                                                      После написания критически важных кусков кода (модули? Не смешите меня!) в подобном стиле — уйдите в другую компанию, этим вы обсепечите торможение в работе ваших преемников, что возымеет свой эффект.
                                                        –3
                                                        проекту очень помогает, когда все употребляют какой-то общий наркотик, например марихуану. Курите весь день, не употребляющих лучше не брать на работу вообще.
                                                          0
                                                          Резюмирую: «Как сделать свою работу плохо? Работайте плохо!»
                                                          Спасибо автору, очень полезная статья.
                                                            0
                                                            Можно работать хорошо и эффективно, но не в пользу проекту.
                                                              0
                                                              А можно работать плохо, но не во вред проекту.
                                                            0
                                                            Ха, актуально :)
                                                              0
                                                              Не расстраивайтесь, в геймдеве неудачных проектов намного больше, чем в других областях. Такая уж специфика.
                                                                0
                                                                школьников и раздолбаев так и манит )
                                                                +1
                                                                Прекрасные советы от обратного. Буду сюда периодически отсылать тех, кто любит заниматься ерудной в команде.
                                                                  0
                                                                  думаю, что тем, кому действительно стоит это прочитать даже не заходят на хабр.
                                                                    +1
                                                                    17) Болейте и заражайте звездной болезнью! Ведь не ровен час, когда надо будет так ярко светить на небосклоне, а работать… работать будут мексиканцы.
                                                                    0
                                                                    Видно, что советы «придумал» pm-практик, потому что любая методика в принципе позволяет элиминировать косяки во время проекта, если пытаться максимально придерживаться методики и рекоммендаций. Хотя для начинающих — просто супер статья, потому что написана доступным для понимания языком.
                                                                      +3
                                                                      Никогда не делайте бэкапов (это ж сколько места будет пропадать под никому ненужными копиями проекта) и используйте самое свежее ПО, собранное собственноручно из альфа-репозиториев разработчиков (все остальное безнадежно устарело и уже никем не используется).
                                                                        +2
                                                                        n) Система контроля версий — для неуверенных в себе.
                                                                        n+1) Отводить время на рефакторинг и ревью кода — пустое занятие. Программисты всегда уверены в своем коде и пишут его идеально.
                                                                          –1
                                                                          Система контроля версий не плохая штука, помогает… Рефакторинг и кодревью использовать только в меру, не злоупотреблять. Рефакторинг не должен приводить к «Эффекту второй системы». Кодревью должно провеодиться часто для новых сотрудников и изредко для давно работающих, для того чтоб помочь увидеть того, что разработчик не заметил.
                                                                          0
                                                                          Этакие «Вредные советы» от мира IT :)
                                                                            0
                                                                            Чувствуется горький опыт автора. Когда начинаешь работу (молодым), с полным энтузиазмом, не обращаешь внимание на эти вещи. Но когда от «ударов об стену» начинают болеть голова, будешь оценивать такие советы. С автором полностью «не» согласен :)
                                                                              0
                                                                              Первый пункт про художника — тысячу раз да! Пишу как пострадавший художник :D
                                                                                0
                                                                                Статья запомниться, так как я пытался на каждое утвержление продумать «противоположно-правильное»))
                                                                                  0
                                                                                  20) В самом начале проекта, когда считаете финансовые затраты, что бы показать инвестору (спонсору) — никогда о себе не думайте. Вы робот, который может работать, без оплаты личных затрат, 25 часов в сутке, и у вас все должно получаться на 100%. А вот ко всем подрядчикам, кого вы наняли- должны относиться с трепетом. Достойная з/п, выходные, не «напрягать», если не успевают и.т.д И к инвестору (спонсору) относиться с пониманием- экономить его деньги (как минимум на себе), выполнять все его просьбы, радовать только хорошими результатами и как можно меньше брать денег на проект, если появяться доп расходы-о которых не было известно раньше. Сами думайте где денюжку взять!

                                                                                  Only users with full accounts can post comments. Log in, please.