|
|
От: |
Mamut
|
http://dmitriid.com |
| Дата: | 10.08.07 11:44 | ||
| Оценка: | |||
Но это — в сторноу. Теперь рассказываю я, как работодатель. У меня есть программист, который за две недели напишет пользовательский интерфейс и программист, который за две недели только-только закончит выправлять ошибки (в основном, связанные с кроссбраузерностью, скорее всего) в своем, родном, с нуля написанном фреймворке. Второй программист в конце этой второй недели вылетит на улицу, потому что моя основная задача — это написание продукта, а не борьба с Яваскриптом.показывает либо полное непонимание того, что от javascript-программиста требуется, либо полное непонимание того, что такое фреймворк, либо и того и другого.Да вообще-то нам javascript-программист теперь скорее всего не понадобится — теперь нам его заменит jQuery.
— Но позвольте, неужели Вы собираетесь положиться на какую-то "дармовщинку" из инета?
— А почему бы и нет, — отвечаете Вы, — вот посмотрите статейку, люди рекомендуют!
Из всего этого следуют Правила большого пальца:
1. Все, что можно купить, нужно покупать (cюда же входит подбор бесплатных компонентов, при их наличии)
2. Все, что нельзя купить, нужно аутсорсить
3. Нельзя аутсорсить "core" — то, за что тебе платят деньги.
Т.е., если ты продаешь программу для бухгалтерии:
1. СУБД, компилятор, визуальные компоненты, инсталлер, хелп вьювер и т.п. — приобретаются
2. Документация, саппорт, скины, кастомные кофигурации — аутсорсятся.
3. Ядро пишется твоей командой высококлассных специалистов, проверяется твоей командой профессионального QA.
Сейчас большинство народу, не принявшего п.1, уже вышли из бизнеса. Сейчас идет освоение п.2.
1. Определиться с основными требованиями к решению. Как правило, происходит на этапе написания SRS, который, вообще говоря, не зависит от того, собственный будет велосипед или готовое решение.
2. Пойти в инет и выбрать некоторое количество решений-кандидатов.
Это делается при помощи Google; как правило более 4х часов на поиски отводить смысла нет. Иногда, в особо запущенных случаях (не удается подобрать хороший запрос для гугла) кидается вопрос в тематический форум(ы). Это удешевляет данный шаг, но делает его дольше (надо дать хотя бы неделю, чтобы завсегдатаи ответили)ю
3. Полученный на предыдущем шаге список просеивается на предмет получения двух-трех кандидатов, которые похожи на то, что надо. Как правило, на это достаточно 8 часов
4. Для отобранных финалистов достаются демы/триалы, и выполняется некоторый набор тестов для проверки п.1. Опять же, жедательно ограничить это дело максимум 8 часов на кандидата.
5. По результатам отбирается лучший вариант. Он и идет в проект — покупается необходимая лицензия и в бой.
Примечания:
— если на шаге 4 ни один из финалистов не выдержал испытания, то надо вернуться на шаг 3 и выбрать других.
— если на шаге 3 не удалось ничего найти, возвращаемся на шаг 2.
— если и здесь нас ждет облом, заключаем, что выхода нет и пишем свой велосипед.
В большинстве случаев, мы получаем готовый результат за одну рабочую неделю одного разработчика. Возможны, конечно, варианты:
1. Если ищется готовое решение для большой проблемы, то имеет смысл умножить оценки для этапа 4 на эмпирический коэффициент.
2. Если ищется какая-нибудь экзотика, то нужно увеличить оценки для этапа 2, т.к. гугл хорошо ищет только популярный контент.
3. В некоторых случаях имеет смысл не делить на шаги, а делать "поиск с возвратами": пытаться зайти как можно дальше с каждым из вариантов, возвращаясь назад в случае обнаружения нерешаемой проблемы. Симптомы того, что у вас и есть некоторый случай:
— не требуется выбрать самое лучшее решение. Достаточно удовлетворительного.
— рынок завален готовыми решениями, и анализ всего списка будет потерей времени.
