дело в том, что параллельно ведется несколько проектов и не бывает такого, что идет провал по деньгам. плюс в сроки проектов заложено немного больше времени, чем требуется. я же писал, что ценник выставляется примерно реальный. Естественно мы закладываем на разработку немного больше на всякий случай.
> «Небыстро, качественно, дешево»,
>>Какой в этом профит? Время — деньги, как вы сказали.
Этот принцип необходимо предлагать клиенту. 2 из 3 — это такая методика. Мы обычно не используем Небыстро, качественно, дешево. Все-таки бизнес
> Баг-фиксинг – это понятно, клиент не должен платить за наши косяки.
>>Почему? Косяки — естественное явление, которого нельзя избежать. Это такая же работа, как написание кода. И должна быть оплачена.
>>Более того, стоит обозначить время, в течении которого будут исправляться косяки после сдачи (на них тоже изначально закладывается бюджет).
Еще раз подчеркиваю — это моя методика и все. Я не говорю брать ее за основу. Время для бесплатного исправления багов всегда прописывается в договоре.
Еще раз подчеркну — это моя схема расчета ценника. Цифры не действительные, а взяты «с потолка». Разработка — это за что мы требуем оплату, Баг-фиксинг — это то, за что мы не берем оплату, так как клиент не должен платить за наши косяки. Интеграция — здесь мы преследуем не получение прибыли, а налаживание более тесного общения с клиентом для дальнейшего сотрудничества и роста.
Тут скорее идет вопрос не о собеседовании, а о реальной работе. Я имел ввиду, что разработчик должен ориентироваться в вопросе быстро и оперативно. Действительно есть задачи требующие достаточно больших временных затрат, но такие задачи решаются в команде. Если же человек сам решает трудную задачу, никто не требует ее решить за 10 минут. Требуется быстро рассуждать и вникать в суть вопроса. Главное не стоять на месте и не тупить
Я имел ввиду, что в критических ситуациях приходится думать очень быстро — это залог успеха. Причем конструктивно думать, с минимумом ошибок. Я зачастую сталкиваюсь с ситуациями, когда необходимо давать очень быстрый ответ. Как пример: в последнем проекте при релизе программы возник очень серьезный баг. Который проявлялся не на всех машинах, а только на конкретных при определенных условиях. И лично мне пришлось давать ответ очень быстро и логично, почему этот баг возник. Если Вы начнете запинаться на таких моментах и в сжатые сроки не предложите конкретного решения, то это может обернуться катастрофой.
Бизнес — это в первую очередь менеджемент. А очень важная составляющая ИТ-бизнеса — это управление проектами. Я имею ввиду для маленькой компании, а не для гигантов. Я думаю Вам показалось, что эта статья по менеджменту только из-за того, что в ней нет рассказах о партнерстве и финансовой стороне дела. И да, кстати, эти правила подходят не только для управления разработкой, но и для управления компанией, к к примеру, если за проект взять «Развитие компании», задачи — это какие-либо дела к примеру «начисление зп, подписание договора аренды, выплата налогов и.т.д и т.п. » И получится, что мы будем управлять компанией также как и любым другим проектом, применяя те же правила
Если Вы грамотно организуете свое сотрудничество с клиентом, то это достаточно важные аспекты. Вы сами творец своей судьбы :) И только Вы позволите не заплатить Вам.
>>Какой в этом профит? Время — деньги, как вы сказали.
Этот принцип необходимо предлагать клиенту. 2 из 3 — это такая методика. Мы обычно не используем Небыстро, качественно, дешево. Все-таки бизнес
> Баг-фиксинг – это понятно, клиент не должен платить за наши косяки.
>>Почему? Косяки — естественное явление, которого нельзя избежать. Это такая же работа, как написание кода. И должна быть оплачена.
>>Более того, стоит обозначить время, в течении которого будут исправляться косяки после сдачи (на них тоже изначально закладывается бюджет).
Еще раз подчеркиваю — это моя методика и все. Я не говорю брать ее за основу. Время для бесплатного исправления багов всегда прописывается в договоре.