Еще очень важно: во время регистрации на сайте — там есть какая-то «незаметная» галочка, если ее отметить — то вам могут дать возможность выступить с докладом на сцене! Которая на фото ниже. Мы ее не нажали, хотя выступить очень хотели, но, потом как только ни упрашивали организаторов «считать что мы нажали» — они были по-европейски непреклонны — «Но вы же не нажали, поэтому нет». Эххх
Узнали про него случайно, из контекстной рекламы, буквально за пару недель до начала. Я бы рекомендовал подать заявку так рано, как сможете. Так у вас и цель будет и время на анализ участников.
Поизучали сайт, честно говоря, не все было понятно. Но зато нашлась ссылка на Программу Альфа где было понятно, что туда может заявиться любой стартап. Подали заявку, потом с нами связались организаторы, где мы кратко рассказали о нашем продукте, его возможностях. После чего они предложили, раз у нас уже действующий продукт, поучавствовать в программе Бета. По их словам — в Альфе очень много совсем-совсем начинающих стартапов, или вообще еще тестируют на уровне идеи. А Бета для тех кто уже что-то из себя представляет. В Бета участвовать лучше, так как и участников поменьше и посетители смотрят внимательней.
Дальше нужно было подать им свой питч — тот который будет написан на стенде, кстати весьма скромном: столик из ДСП и плакат с логотипом, адресом сайта и вот этим питчем.
Вот тут надо было очень постараться, потому что когда посетители проходят мимо, они читают именно его, так как названия компаний мало о чем говорят. Мы очень долго над ним думали. Наш был такой:
SaaS Platform replacing mobile apps with 50X times more efficient omni-channel PWAs
и я скажу он вместе с вентилятором заставлял людей останавливаться и спрашивать — «а как это?»
Когда вы подадите заявку и отправите логотип и питч, сразу нужно будет оплачивать участие. В стоимость стенда входило 3 билета, мы втроем и поехали.
Кроме того, на саммите планируются разные круглые столы, "час с инвестором" и пр. туда тоже надо подать заявку заранее, имейте ввиду 70К посетителей, конкуренция огромная.
На «час с инвестором» — стоит податься, так как вам дается на самом деле 20 минут, но возможность задать острые для вас вопросы одному из акул ИТ бизнеса, которого вам назначат.
Но чтобы туда податься — надо заранее написать 3 вопроса к этому инвестору, и если они будут интересные, то вас пригласят. Главное не питчить ему и не продавать себя. Задавайте конкретные вопросы по выходу на рынок, по росту и пр. На этой 20-минутке если он ответит быстро, будет возможность задать еще 1-2 вопроса.
На доклады в большом зале не ходили, так как он достаточно далеко от павильонов и там свое расписание и своя огромная очередь.
все так! Но пока, по факту, я сталкиваюсь с тем, что в связи с недостатком обучения программированию и базам данных — то что делают программисты, считая «Правильным способом», ничем не отличается от костыльного говнокода. Я не имею ввиду тебя, я не видел твой код еще.
Проблема в том, что основы программирования среди всех моих 20+ программеров, которые работали — от силы знал 1 или 2. Все остальные — самоучки, САМи считающие что они знают как надо.
В итоге получалось — делали ли они говнокод по моему заданию, или делали супер-пупер расширяемую систему — получалось одно и то же — только разница во времени была в несколько раз.
И НИ РАЗУ!!! Не зависимо от того как было сделано, я не смог использовать существующий код в другом проекте. Вот тебе и факт.
Теперь в ситуации текущего проекта, который мне нужно сдать как можно быстрее — я конечно выберу «говнокод», так как он имеет выигрыш во времени. Других отличий нет.
Я буду очень рад, если хотя бы ОДИН раз, существующий код будет использован в другом проекте и снизит трудоемкость этого участка до банального копипаста. Пока я этого не наблюдаю.
Ну и еще — наличие или отсутствие ТЗ — довольно мало влияет на время разработки.
Есть ТЗ — все равно придется переделывать какую-нибудь концептуальную хрень, которая сильно затянет срок.
Нет ТЗ — все равно придется переделывать какую-нибудь концептуальную хрень, которая сильно затянет срок.
Единственное, что иметь ТЗ удобно программисту — как руководство к действию, спокойно почитать и не отвлекать РП
Ну и если закачик хочет фантастическую штуку — можно обосновать что этого в ТЗ не было.
А и еще — бывает что возникает большой пласт работы в конце проекта и необходимо сделать дополнительную фичу, которая в ТЗ не прописана, но всем понятно, что если ее не сделать — проект никому не нужен будет.
Уже который раз сталкиваешься — как бы ни писали ТЗ, все равно оно будет изменено, все равно чего-то не учтешь.
Как бы ни заинтересован был заказчик в результате — с его стороны все равно будут задержки по просмотру/приемке/утверждению/согласованию.
Я для себя уже принял как факт:
1. Оценку программиста надо умножить на 2 и добавить еще чуть-чуть. За 6 лет работы РП — сходится в 95% случаев
2. В ТЗ будут внесены изменения, причем такие, что обосновать дополнительную стоимость будет ОЧЕНЬ сложно, а время на решение задачи увеличится и придется что-то переделывать.
3. Заказчик быстро не реагирует. И надо закладывать в буфер времени (получения оплаты) — некоторую величину, которая тем больше, чем крупнее заказчик.
4. Не добавлять программистов к проекту, когда он уже заканчивается (ну или стремится к этому) — золотое правило еще от Брукса.
5. Для больших проектов — не использовать новые, непроверенные временем инструменты или технологии.
А как же Teamwork project manager?
Она прямо специально заточена для разработки ПО и сайтов. Ребята постоянно выкладывают апдейты, даже с Dropbox подружились недавно. Очень много фич, и шаблоны списков задач и удобная работа с электронной почтой. На замечания и баги очень оперативно реагируют, пару недель назад добавили например 'оценочное время выполнения задачи' ну или как правильно перевести 'Add estimated completion time to each task'
ОГО! Уменьшить? И каким образом вы можете это объяснить?
p.s. Спасибо за Рейнвотера («Как пасти котов. Наставление для программистов, руководящих другими программистами») — пошел читать :)
У меня есть несколько «заваленных» проектов, в основном по срокам. Буду признателен, если вы продолжите эту тему! Пост на 5 с +.
Можете описать, что ИМЕННО должен делать ПМ? Конкретно, а не просто «руководить»… Хочу определиться, какие функции на него возложить, и кого из программистов «прокачивать» до руководителя.
Пытался, нет у них такого. Если быть конкретным — это два сайта — mediatemple (хостинг) и worksection (управление проектами). Ну нет у них платежей через р/с!
Хоть отношения к делу не имеет, но продукт заказчик сам попросил установить.
И по формулировке «бороться с человеческим фактором» — возможно, нужно было написать «Как бороться с нежеланием сотрудников работать во внедренном ПО?», так наверное более четко звучит вопрос.
Идеальный вариант — пришли, установили, обучили, начали работать — возникли вопросы / пожелания — доработали софт — работаем спокойно. Все сыты и целы.
Реальный вариант — пришли, установили, обучили, заглохло…
Мой вопрос в том — что именно нужно делать, чтобы процесс пошел так как нужно. А бороться, действительно бесполезно :)
Меня больше всего впечатляет вот эта
Поизучали сайт, честно говоря, не все было понятно. Но зато нашлась ссылка на Программу Альфа где было понятно, что туда может заявиться любой стартап. Подали заявку, потом с нами связались организаторы, где мы кратко рассказали о нашем продукте, его возможностях. После чего они предложили, раз у нас уже действующий продукт, поучавствовать в программе Бета. По их словам — в Альфе очень много совсем-совсем начинающих стартапов, или вообще еще тестируют на уровне идеи. А Бета для тех кто уже что-то из себя представляет. В Бета участвовать лучше, так как и участников поменьше и посетители смотрят внимательней.
Дальше нужно было подать им свой питч — тот который будет написан на стенде, кстати весьма скромном: столик из ДСП и плакат с логотипом, адресом сайта и вот этим питчем.
Вот тут надо было очень постараться, потому что когда посетители проходят мимо, они читают именно его, так как названия компаний мало о чем говорят. Мы очень долго над ним думали. Наш был такой:
и я скажу он вместе с вентилятором заставлял людей останавливаться и спрашивать — «а как это?»
Когда вы подадите заявку и отправите логотип и питч, сразу нужно будет оплачивать участие. В стоимость стенда входило 3 билета, мы втроем и поехали.
Кроме того, на саммите планируются разные круглые столы, "час с инвестором" и пр. туда тоже надо подать заявку заранее, имейте ввиду 70К посетителей, конкуренция огромная.
На «час с инвестором» — стоит податься, так как вам дается на самом деле 20 минут, но возможность задать острые для вас вопросы одному из акул ИТ бизнеса, которого вам назначат.
Но чтобы туда податься — надо заранее написать 3 вопроса к этому инвестору, и если они будут интересные, то вас пригласят. Главное не питчить ему и не продавать себя. Задавайте конкретные вопросы по выходу на рынок, по росту и пр. На этой 20-минутке если он ответит быстро, будет возможность задать еще 1-2 вопроса.
На доклады в большом зале не ходили, так как он достаточно далеко от павильонов и там свое расписание и своя огромная очередь.
Проблема в том, что основы программирования среди всех моих 20+ программеров, которые работали — от силы знал 1 или 2. Все остальные — самоучки, САМи считающие что они знают как надо.
В итоге получалось — делали ли они говнокод по моему заданию, или делали супер-пупер расширяемую систему — получалось одно и то же — только разница во времени была в несколько раз.
И НИ РАЗУ!!! Не зависимо от того как было сделано, я не смог использовать существующий код в другом проекте. Вот тебе и факт.
Теперь в ситуации текущего проекта, который мне нужно сдать как можно быстрее — я конечно выберу «говнокод», так как он имеет выигрыш во времени. Других отличий нет.
Я буду очень рад, если хотя бы ОДИН раз, существующий код будет использован в другом проекте и снизит трудоемкость этого участка до банального копипаста. Пока я этого не наблюдаю.
Есть ТЗ — все равно придется переделывать какую-нибудь концептуальную хрень, которая сильно затянет срок.
Нет ТЗ — все равно придется переделывать какую-нибудь концептуальную хрень, которая сильно затянет срок.
Единственное, что иметь ТЗ удобно программисту — как руководство к действию, спокойно почитать и не отвлекать РП
Ну и если закачик хочет фантастическую штуку — можно обосновать что этого в ТЗ не было.
А и еще — бывает что возникает большой пласт работы в конце проекта и необходимо сделать дополнительную фичу, которая в ТЗ не прописана, но всем понятно, что если ее не сделать — проект никому не нужен будет.
Как бы ни заинтересован был заказчик в результате — с его стороны все равно будут задержки по просмотру/приемке/утверждению/согласованию.
Я для себя уже принял как факт:
1. Оценку программиста надо умножить на 2 и добавить еще чуть-чуть. За 6 лет работы РП — сходится в 95% случаев
2. В ТЗ будут внесены изменения, причем такие, что обосновать дополнительную стоимость будет ОЧЕНЬ сложно, а время на решение задачи увеличится и придется что-то переделывать.
3. Заказчик быстро не реагирует. И надо закладывать в буфер времени (получения оплаты) — некоторую величину, которая тем больше, чем крупнее заказчик.
4. Не добавлять программистов к проекту, когда он уже заканчивается (ну или стремится к этому) — золотое правило еще от Брукса.
5. Для больших проектов — не использовать новые, непроверенные временем инструменты или технологии.
Тень от цифры 12 на плакатах была ввиде 5ки… А я уж думал сейчас выйдет 5 фон, так хоть цены на 4 скинут
Она прямо специально заточена для разработки ПО и сайтов. Ребята постоянно выкладывают апдейты, даже с Dropbox подружились недавно. Очень много фич, и шаблоны списков задач и удобная работа с электронной почтой. На замечания и баги очень оперативно реагируют, пару недель назад добавили например 'оценочное время выполнения задачи' ну или как правильно перевести 'Add estimated completion time to each task'
p.s. Спасибо за Рейнвотера («Как пасти котов. Наставление для программистов, руководящих другими программистами») — пошел читать :)
Можете описать, что ИМЕННО должен делать ПМ? Конкретно, а не просто «руководить»… Хочу определиться, какие функции на него возложить, и кого из программистов «прокачивать» до руководителя.
И по формулировке «бороться с человеческим фактором» — возможно, нужно было написать «Как бороться с нежеланием сотрудников работать во внедренном ПО?», так наверное более четко звучит вопрос.
Идеальный вариант — пришли, установили, обучили, начали работать — возникли вопросы / пожелания — доработали софт — работаем спокойно. Все сыты и целы.
Реальный вариант — пришли, установили, обучили, заглохло…
Мой вопрос в том — что именно нужно делать, чтобы процесс пошел так как нужно. А бороться, действительно бесполезно :)