Чем быстрее поддержка, тем быстрее мы увидим лучший web. От этих бюрократов можно ждать десятками лет утверждения того, что и так уже необходимо в сегодняшних реалиях. Если браузеры/не все браузеры двигаются к светлому будущему, то это надо обойти. Надоело уже ставить костыли типа -moz и -webkit а еще кучи js кода и следить за кроссбраузерностью при этом, объяснять заказчику, что все красоты он увидит в Chrome, а не в его любимом IE6.
лучше бы встроили проверку на поддержку браузером HTML5 или если её нет, то по возможности компенсировали эти недостатки типа placeholder и пр., чтобы верстальщики делали на HTML5 не заботясь о совместимости браузеров.
ПОЧЕМУ вопрос звучит, как система управления проектами, а в вариантах присутствуют issue-трекеры (RedMine, ClockingIT и т.д.)? Это же разные понятия.
Есть уровень кода, там SVN/Git
Есть уровень задач, там всякие трекеры RedMine, Trac, Mantis и пр.
А есть уровень управления проектами тут вот должны быть MS Project и пр.
Понятно, что многие трекеры поддерживают процессы реализации проекта и даже некоторые фичи по планированию проекта, но это не делает из них чистого инструмента ведения проектов.
Если цель получать деньги — забудьте про уважение, будьте любезны и почтительны, но если не хотите, чтобы бизнес прогорел четко просчитывайте функционал, сроки и деньги. Приятно или неприятно работать с каким-либо заказчиком — это не так уж важно.
не думаю, что этот топик может правильно обосновать неправоту автора той статьи, ибо автор, видимо, пытался опровергнуть мнение, что:
* работать надо много -> ну вот он и работает всего по 4 часа в день
* жизнь должна быть трудной -> он придумал, как для себя упростить проблему принятия решений (делать или не делать — значит теперь для него все просто)
* времени должно не хватать -> благодаря своему подходу оценки будущих действий через деньги, времени у него теперь много
Конечно, того автора немного заносит, но может это просто примеры для объяснения своего подхода…
Не все так однозначно и с рабочим временем, например, работа, которая даст удельно за час только 20% от часовой ставки может быть сделана исходя из других побуждений. Это как с написанием своей книги, доход от неё в продажах очень маленький даже, если продавать за дорого, времени расходует вагоны, по вашему — не выгодно, но есть «побочный» эффект (side effect) — ваши регалии и оценка вас как специалиста потенциальными работодателями и партнерами. И тут вы повышаете стоимость себя как бренда, а это потенциальные большие заработки, только вот их размер сложно просчитать.
Раньше я бы считал, что просят юзеры, если это не убивает систему, то надо делать, особенно, если за это платят.
Но недавно ознакомился с интереснейшей книгой «Цель 3. Необходимо, но недостаточно», про ТОС «Теорию ограничений систем». Там было нечто похожее и они решили вопрос кардинально иначе.
Описывать здесь не имеет смысла, кто захочет, тот найдет и почитает. Более полезной книги (серии книг про ТОС) по бизнесу и по управлению проектами еще не встречал. А стартапы и разработка это в первую очередь бизнес.
Привязывать сосиски к рефакторингу и код-ревью (тут еще прозвучало юнит-тестирование) явно не для всех проектов, я бы сказал, что актуально для разработки и то нестандартных решений. Есть ведь куча других типов проектов даже в IT. Поэтому считаю это весьма спорным и далеко не универсальным.
— зачем тебе сайт?
— ну я не совсем уверен, но вроде нужен, как бы
— приходи когда действительно поймешь зачем тебе сайт
если бы во всех студиях был такой диалог, то все бизнес-сайты были для бизнеса
Есть уровень кода, там SVN/Git
Есть уровень задач, там всякие трекеры RedMine, Trac, Mantis и пр.
А есть уровень управления проектами тут вот должны быть MS Project и пр.
Понятно, что многие трекеры поддерживают процессы реализации проекта и даже некоторые фичи по планированию проекта, но это не делает из них чистого инструмента ведения проектов.
Как-то так. Остальное вопрос интеграции.
* работать надо много -> ну вот он и работает всего по 4 часа в день
* жизнь должна быть трудной -> он придумал, как для себя упростить проблему принятия решений (делать или не делать — значит теперь для него все просто)
* времени должно не хватать -> благодаря своему подходу оценки будущих действий через деньги, времени у него теперь много
Конечно, того автора немного заносит, но может это просто примеры для объяснения своего подхода…
И таких примеров масса.
2. Не обязательно, наставником — да.
2. Сколько книг по управлению прочитали за последние полгода? (банально, но важно)
3. Как вы управляете рисками на проекте?
Но недавно ознакомился с интереснейшей книгой «Цель 3. Необходимо, но недостаточно», про ТОС «Теорию ограничений систем». Там было нечто похожее и они решили вопрос кардинально иначе.
Описывать здесь не имеет смысла, кто захочет, тот найдет и почитает. Более полезной книги (серии книг про ТОС) по бизнесу и по управлению проектами еще не встречал. А стартапы и разработка это в первую очередь бизнес.