Все тут неоднозначно… Оставив в покое желающих внести свои байты кода в открытую ОС, например разработчикам приложений, а уж тем более пользователям — главное — бесплатность стабильность ОС. Ну и может быть еще аргумент — стать разработчиком apps под iOS стоит денег, a c Android — тут действительно welcome-open. А с другой стороны — заработать на приложении под iPhone/iPad сейчас на порядок легче. И так-ли они отличаются друг от друга — эти корпорации-монстры в своей долгосрочной политике по отношению к нам?
Работа — и есть жизнь, во всяком случае большая ее часть (или бОльшая — как кому повезло :))… Понимаю раздражение, которое вызывает сама идея систематизировать каждый «пук». Использовать тайм-менеджмент надо в личных корыстных целях — или не использовать совсем. Если раздражает — значит мешает работе, т.е. вреден. Но точно полезен — если реально помог, а тем более — принес денежку!
Есть польза от тайм-менеджмента, есть… Например — структурировать свои мелкие задачи по разработке и поддержке, и как результат — получить учет потраченного времени для почасовой оплаты клиентом. Мозги тут не помогут, да и блокнотик — тоже ))
Звучит фатально.
Наверное поэтому процент успешного «выхода» it-проектов так низок.
По своему опыту могу сказать, что стараясь клиентов не обижать имею следующую собственную статистику с 1998 года по сегодняшний день — при 12-15 вэб-проектах в год — один из них по разным причинам, в т. ч. видимо и по моей вине заканчивается ничем, т.е. не заканчивается. Лучше пока не получается, как ни старайся.
>>Если бы все риски оценили — не было бы этого поста
>>Не ехать — или ехать в вашей ситуации — вопрос очень субъективный, но отдавать себе отчет в том, что человек может не сделать работу или сделать ее не в срок — надо
>>Согласен, что все в ТЗ не пропишешь, но раз уж риски велики, а проект вы все-таки делаете, переделайте ТЗ на несколько мелких этапов, размером в 1 человеко-неделю и проверяйте и платите частями
Поскольку сам исполнитель не высказался, можно сказать что заказчик сделал не так:
1) не оценил риски проекта — первый проект с этим исполнителем, сжатые сроки и т.д.
2) не отреагировал на первый сигнал — «Водитель на место встречи опаздывает на час»
3) не отреагировал на все последующие явные сигналы опасности для проекта — «На дороге его останавливает каждый гаишник, он постоянно норовит куда-то свернуть с прямой дороги до места, рассказывая что так быстрее, но постоянно приходится возвращаться потому что «быстрая дорога» ведет в тупик»
4) не определил четкие взаимоотношения с исполнителем — кто проводит начальное тестирование, сроки внесения изменений и возможные санкции
список можно продолжить…
Но суть в том, что заказчик в таких проектах — ключевая фигура, определяющая сроки сдачи проекта, и от него по сути эти сроки зависят. Иногда исполнитель может принять решение потерять часть денег на штрафные санкции, но сделать проект чуть позже. Заказчик такой вариант тоже должен учесть. Представлять себя невинной жертвой фрилансерства — наивно. Раз фрилансеры есть, значит они востребованы.
И последняя крамольная мысль: работать можно абсолютно с любым исполнителем и заказчиком, и даже если Вы не все учли в ТЗ и договоре — не отчаивайтесь, просто держите «руку на пульсе» проекта и вовремя реагируйте на происходящее. Не запускайте проект.
бесплатностьстабильность ОС. Ну и может быть еще аргумент — стать разработчиком apps под iOS стоит денег, a c Android — тут действительно welcome-open. А с другой стороны — заработать на приложении под iPhone/iPad сейчас на порядок легче. И так-ли они отличаются друг от друга — эти корпорации-монстры в своей долгосрочной политике по отношению к нам?Наверное поэтому процент успешного «выхода» it-проектов так низок.
По своему опыту могу сказать, что стараясь клиентов не обижать имею следующую собственную статистику с 1998 года по сегодняшний день — при 12-15 вэб-проектах в год — один из них по разным причинам, в т. ч. видимо и по моей вине заканчивается ничем, т.е. не заканчивается. Лучше пока не получается, как ни старайся.
>>Не ехать — или ехать в вашей ситуации — вопрос очень субъективный, но отдавать себе отчет в том, что человек может не сделать работу или сделать ее не в срок — надо
>>Согласен, что все в ТЗ не пропишешь, но раз уж риски велики, а проект вы все-таки делаете, переделайте ТЗ на несколько мелких этапов, размером в 1 человеко-неделю и проверяйте и платите частями
Риски существенно снизятся
1) не оценил риски проекта — первый проект с этим исполнителем, сжатые сроки и т.д.
2) не отреагировал на первый сигнал — «Водитель на место встречи опаздывает на час»
3) не отреагировал на все последующие явные сигналы опасности для проекта — «На дороге его останавливает каждый гаишник, он постоянно норовит куда-то свернуть с прямой дороги до места, рассказывая что так быстрее, но постоянно приходится возвращаться потому что «быстрая дорога» ведет в тупик»
4) не определил четкие взаимоотношения с исполнителем — кто проводит начальное тестирование, сроки внесения изменений и возможные санкции
список можно продолжить…
Но суть в том, что заказчик в таких проектах — ключевая фигура, определяющая сроки сдачи проекта, и от него по сути эти сроки зависят. Иногда исполнитель может принять решение потерять часть денег на штрафные санкции, но сделать проект чуть позже. Заказчик такой вариант тоже должен учесть. Представлять себя невинной жертвой фрилансерства — наивно. Раз фрилансеры есть, значит они востребованы.
И последняя крамольная мысль: работать можно абсолютно с любым исполнителем и заказчиком, и даже если Вы не все учли в ТЗ и договоре — не отчаивайтесь, просто держите «руку на пульсе» проекта и вовремя реагируйте на происходящее. Не запускайте проект.