Косвенно вся организация имеет отношения к продажам.
Вопрос в рабочих обязанностях сотрудников.
Управленец над сейлами и над тех персоналом сразу, это должность очень высокого уровня. Это скорее всего один из топ менеджеров, который не будет влезать в детали проектов, а будет следить за бизнес показателями компании.
В крайнем случае он может решать конфликты между сейлами и технарями.
Вовсе нет.
Это все равно что сказать, что надо разрабатывать обычное десктопное решение и клиент-серверное приложение одинаково.
Риски у этих разработок разные, целевая аудитория разная, жизненный цикл проектов разный.
Не важно откуда «вышел» менеджер. У него есть круг обязанностей, которые он должен исполнять.
Сделать качественный продукт удовлетворяющий потребности заказчика, его прямая обязанность. Все это конечно с поправкой на бюджет и сроки.
Вообще логика — откуда вышел человек — почти всегда используется для объяснения его ошибок. Есть должности, есть соответствующие им навыки и компетенции. Можно взять на испыталку, того, кто не полностью соответствует, но тогда надо доучить его.
В любом случае в длительной перспективе вас не должно волновать откуда пришел ваш сотрудник, важно что он делает свою работу хорошо.
Удержать клиента конкретно с этим проектом или превратить его в постоянного заказчика или вашего благодарного клиента?
Это разные вещи.
Если вы не поймете, что ему на самом деле надо, то если у него есть мозг, то он поймет, что ему впарили что-то бесполезное и не будет больше заказывать у вас софт, а еще может своим партнерам по бизнесу рассказать про особенности работы с такой компанией.
Конечно стратегию Trash&Cash еще никто не отменял, но тогда самым главным человеком в компании будет менеджер по поиску идиотов клиентов. А от технических специалистов будет очень мало что зависеть.
Заказчика нужно удерживать, это не вопрос.
Я говорю про чувство ответственности у людей.
В вашем случае, по всей видимости, как раз менеджер и проводит процедуру уяснения задачи, чтобы реальные исполнители, да и он сам, четко понимали что необходимо сделать.
Здесь есть четкое разделение труда. Есть менеджеры или лиды, в обязанности которых как раз входит нормально декомпозировать задачу. Есть исполнители, которые потом будут превращать поставленные ими задачи в код.
На каждом этапе важно выполнение всех этих трех условий. Если менеджер не смог понять, чего от него хочет заказчик, то он должен создать у заказчика нужные ему ожидания. Важно чтобы видение задачи было одинаковым с обоих сторон. Иначе ничего хорошего у вас не получится.
Аналогично программисту надо четко понять чего от него хотят.
И при этом не забывайте, что любой продукт можно и нужно делать итеративно. Поэтому можно спокойно согласовывать требования к каждой итерации постепенно фиксируя важные элементы и углубляясь в детали.
Если я ничего не путаю, то по базе в 32-ух разрядной ОС процессу доступно только 2Гб. Т.е. даже если на компе реально установлено больше оперативной памяти, она не может быть доступна одному процессу.
Данные ключи позволяют сдвинуть это ограничение.
Более детально лучше смотреть в документации Microsoft.
Например тут.
support.microsoft.com/kb/316739
Если я ничего не путаю, то по базе в 32-ух разрядной ОС процессу доступно только 2Гб. Т.е. даже если на компе реально установлено больше оперативной памяти, она не может быть доступна одному процессу.
Данные ключи позволяют сдвинуть это ограничение.
Более детально лучше смотреть в документации Microsoft.
Например тут. support.microsoft.com/kb/316739
Все сильно зависит от психотипа человека. Следование парадигмам для многих или не даст результата или вообще может оказаться губительно.
Насчет не впадания в параною, в принципе все достаточно просто. Надо спокойно формировать приоритеты своего развития. Далее каждый месяц/неделю/год (осознаваемый и прогнозируемый промежуток времени) можно спокойно вспоминать что вы планировали, смотреть что получилось. Далее смотрим на список того, что осталось, переназначаем приоритеты, смотрим на то что реально успеть за отведенное время.
А чем будет принципиально отличаться бета онлайн продукта от беты коробочного?
И то и другое распространяется через интернет и то и друго предполагает наличие патчей.
Так что для людей готовых играть в бета версии разницы не будет. Им по любому нужен коннект к сети и готовность качать патчи.
Вообще соблазн выпустить сырой продукт, это скорее к управлению бизнесом, а не QA.
Вопрос в рабочих обязанностях сотрудников.
Управленец над сейлами и над тех персоналом сразу, это должность очень высокого уровня. Это скорее всего один из топ менеджеров, который не будет влезать в детали проектов, а будет следить за бизнес показателями компании.
В крайнем случае он может решать конфликты между сейлами и технарями.
Из которого ОС себе резервирует по базе 2Гб.
После применения ключа винда пытается влезть в 1Гб.
Это все равно что сказать, что надо разрабатывать обычное десктопное решение и клиент-серверное приложение одинаково.
Риски у этих разработок разные, целевая аудитория разная, жизненный цикл проектов разный.
Сделать качественный продукт удовлетворяющий потребности заказчика, его прямая обязанность. Все это конечно с поправкой на бюджет и сроки.
Вообще логика — откуда вышел человек — почти всегда используется для объяснения его ошибок. Есть должности, есть соответствующие им навыки и компетенции. Можно взять на испыталку, того, кто не полностью соответствует, но тогда надо доучить его.
В любом случае в длительной перспективе вас не должно волновать откуда пришел ваш сотрудник, важно что он делает свою работу хорошо.
Это разные вещи.
Если вы не поймете, что ему на самом деле надо, то если у него есть мозг, то он поймет, что ему впарили что-то бесполезное и не будет больше заказывать у вас софт, а еще может своим партнерам по бизнесу рассказать про особенности работы с такой компанией.
Конечно стратегию Trash&Cash еще никто не отменял, но тогда самым главным человеком в компании будет менеджер по поиску
идиотовклиентов. А от технических специалистов будет очень мало что зависеть.Я говорю про чувство ответственности у людей.
В вашем случае, по всей видимости, как раз менеджер и проводит процедуру уяснения задачи, чтобы реальные исполнители, да и он сам, четко понимали что необходимо сделать.
На каждом этапе важно выполнение всех этих трех условий. Если менеджер не смог понять, чего от него хочет заказчик, то он должен создать у заказчика нужные ему ожидания. Важно чтобы видение задачи было одинаковым с обоих сторон. Иначе ничего хорошего у вас не получится.
Аналогично программисту надо четко понять чего от него хотят.
И при этом не забывайте, что любой продукт можно и нужно делать итеративно. Поэтому можно спокойно согласовывать требования к каждой итерации постепенно фиксируя важные элементы и углубляясь в детали.
Есть мысль высказанная в сообщении, если есть нормальная аргументация против, то можно обсудить.
Иначе почти наверняка тебе сделают совсем не то, что ты заказывал.
Кто в этом виноват, драйвера или операционная система я не могу судить.
Данные ключи позволяют сдвинуть это ограничение.
Более детально лучше смотреть в документации Microsoft.
Например тут.
support.microsoft.com/kb/316739
Данные ключи позволяют сдвинуть это ограничение.
Более детально лучше смотреть в документации Microsoft.
Например тут.
support.microsoft.com/kb/316739
Насчет не впадания в параною, в принципе все достаточно просто. Надо спокойно формировать приоритеты своего развития. Далее каждый месяц/неделю/год (осознаваемый и прогнозируемый промежуток времени) можно спокойно вспоминать что вы планировали, смотреть что получилось. Далее смотрим на список того, что осталось, переназначаем приоритеты, смотрим на то что реально успеть за отведенное время.
И то и другое распространяется через интернет и то и друго предполагает наличие патчей.
Так что для людей готовых играть в бета версии разницы не будет. Им по любому нужен коннект к сети и готовность качать патчи.
Вообще соблазн выпустить сырой продукт, это скорее к управлению бизнесом, а не QA.