Заметки для игры в бизнес. Часть 2

[Kirpa]

Интересная статья.

Но вот с этим моментом:

Скорость мышления – скорость мышления для ИТ-специалиста очень критична, на мой взгляд.

не согласен. Подавляющее большинство ИТ-спецов не работает в режиме реального времени, где от скорости решения зависит что-то важное. Если человеку требуется даже 10 минут, чтобы включиться в задачу, он всё равно сможет работать в ИТ. Чаще всего гораздо важнее результат — удачное решение перекрывает время, потраченое на его поиски. А неудачное может привести к тому, что время на его реализацию будет потрачено впустую и придётся выбирать другой путь.

[vyadzmak]

Я имел ввиду, что в критических ситуациях приходится думать очень быстро — это залог успеха. Причем конструктивно думать, с минимумом ошибок. Я зачастую сталкиваюсь с ситуациями, когда необходимо давать очень быстрый ответ. Как пример: в последнем проекте при релизе программы возник очень серьезный баг. Который проявлялся не на всех машинах, а только на конкретных при определенных условиях. И лично мне пришлось давать ответ очень быстро и логично, почему этот баг возник. Если Вы начнете запинаться на таких моментах и в сжатые сроки не предложите конкретного решения, то это может обернуться катастрофой.

[Kirpa]

Быстро дать ответ — это не то же самое, что быстро найти решение :) Первое требует реакции в течении нескольких секунд и это важное качество для тех, кто общается с клиентами. Но это не является задачей ИТ-спеца, это менеджмент и продажи. А вот нахождение решения, в условиях ИТ, обычно подразумевает минуты-часы и даже дни.

[Yoschi]

Поддерживаю предыдущего оратора. Программисты как правило интроверты и им вовсе непросто давать быстрые и четкие ответы на собеседовании. И это вовсе не значит, что они не могут принимать быстрые и четкие решения оставаясь наедине с компьютером.

[vyadzmak]

Тут скорее идет вопрос не о собеседовании, а о реальной работе. Я имел ввиду, что разработчик должен ориентироваться в вопросе быстро и оперативно. Действительно есть задачи требующие достаточно больших временных затрат, но такие задачи решаются в команде. Если же человек сам решает трудную задачу, никто не требует ее решить за 10 минут. Требуется быстро рассуждать и вникать в суть вопроса. Главное не стоять на месте и не тупить

[jandosul]

Звучит как какбы быстро отмазаться

[Nem427]

Это Вам, как директору, нужно давать быстрый ответ, да ещё и в условиях неопределённости. А программисту, как технарю, нужно дать правильный ответ. Чтобы дать правильный ответ, необходимо его определить. В описываемом Вами же примере баг, который проявлялся не на всех машинах. Технарям нужно отловить момент, в который проявляется баг и найти отличия между машинами с багом и без. И это мгновенно они сделать не смогут.

[Kirpa]

перенос

[Yoschi]

Непонятен момент с формированием цены. Вы пишете, что берёте деньги только за разработку. То есть, фактически за 1/3 полной работы. Пользуясь теми же цифрами, что в примере, вам нужно 20$ на разработку, 20$ на багфикс и 20$ на интеграцию. Но с клиента вы берёте только 25$. Откуда же прибыль?

[vyadzmak]

Еще раз подчеркну — это моя схема расчета ценника. Цифры не действительные, а взяты «с потолка». Разработка — это за что мы требуем оплату, Баг-фиксинг — это то, за что мы не берем оплату, так как клиент не должен платить за наши косяки. Интеграция — здесь мы преследуем не получение прибыли, а налаживание более тесного общения с клиентом для дальнейшего сотрудничества и роста.

[Yoschi]

Я просто пытаюсь разобраться. Правильно ли я понимаю, что это для клиента картина такова, что вы берёте только за разработку? А фактически в эту плату заложены предполагаемые расходы в будущем. Ведь если вы сами заплатили своим людям за три дня работы, а получили деньги только за один, то вы в минусе.

[vyadzmak]

дело в том, что параллельно ведется несколько проектов и не бывает такого, что идет провал по деньгам. плюс в сроки проектов заложено немного больше времени, чем требуется. я же писал, что ценник выставляется примерно реальный. Естественно мы закладываем на разработку немного больше на всякий случай.

[vyadzmak]

> «Небыстро, качественно, дешево»,
>>Какой в этом профит? Время — деньги, как вы сказали.
Этот принцип необходимо предлагать клиенту. 2 из 3 — это такая методика. Мы обычно не используем Небыстро, качественно, дешево. Все-таки бизнес

> Баг-фиксинг – это понятно, клиент не должен платить за наши косяки.
>>Почему? Косяки — естественное явление, которого нельзя избежать. Это такая же работа, как написание кода. И должна быть оплачена.
>>Более того, стоит обозначить время, в течении которого будут исправляться косяки после сдачи (на них тоже изначально закладывается бюджет).
Еще раз подчеркиваю — это моя методика и все. Я не говорю брать ее за основу. Время для бесплатного исправления багов всегда прописывается в договоре.

[PavelT]

6. Informix?

[vyadzmak]

Нет. Не он.

[Krovosos]

Странно, что так мало положительных отзывов. Спасибо за полезную информацию!

[vyadzmak]

Спасибо Вам за комментарий. :) Надеюсь их будет больше

[Sighurd]

Спасибо за статью. Спорить с ней не хочется и не нужно — это же просто ваш опыт и ваши выводы. По большинству пунктов я с вами согласен, но все равно благодарен вам по причине того, что в последнее время ловлю себя на «Человеку свойственно «замыливать глаз», то есть очень долго решать проблему и не видеть других подходов, кроме одного»

P.S. Кстати, относительно недавно пришлось предложить клиенту «Небыстро, качественно, дешево». Потому что понимал, что кое-чему очень перспективному придется научиться уже «в бою». Клиент готов рискнуть ради «небыстро и дешево», мне нужно «очень перспективное» — в итоге все довольны. Да и риск невелик — на крайний случай старое и проверенное решение в запасе имеется всегда.

[asfd]

Обе статьи хороши. На собственном опыте могу подписаться под каждым пунктом.