Sent from my iPad
среда, 29 августа 2012 г.
понедельник, 27 августа 2012 г.
воскресенье, 19 августа 2012 г.
Разработка технического задания (ТЗ) на программный продукт с точки зрения заказчика / Хабрахабр
 |  | |
Разработка технического задания (ТЗ) на программный продукт с точки зрения заказчика из песочницы
За время своей работы мне удалось взглянуть на процесс разработки технических заданий на программные продукты с нескольких точек зрения. С точки зрения аналитика – непосредственного исполнителя работ, с точки зрения руководителя проекта со стороны исполнителя, организующего процесс создания ТЗ, с точки зрения руководителя группы разработчиков, реализующих эти самые ТЗ, а также с точки зрения заказчика системы, впоследствии принимающего решение по разработанному ранее ТЗ.
Надо сказать, что у каждой из этих заинтересованных сторон свои требования и свое видение того, каким должно быть «хорошо написанное ТЗ». Например, у заказчика и исполнителя могут быть совершенно противоположные мнения на этот счет. Исполнитель может быть заинтересован в максимально подробном ТЗ для того, чтобы максимально формализовать свои обязательства по функционалу создаваемого решения. При этом заказчик, который точно не определился с параметрами будущей системы или у которого «ветер в голове», может требовать более общих формулировок, описания системы крупными мазками для того, чтобы потом попытаться включить в рамки оговоренного бюджета новые требования. Конечно же, при другом «менталитете» заказчика и исполнителя все может быть с точностью до наоборот. Сейчас мне хотелось бы остановиться именно на разработке ТЗ с точки зрения его заказчика, рассмотрев возможные ситуации, цели и тактики поведения.
Для начала определимся с тем, какие факторы влияют на разработку ТЗ. Прежде всего, это степень понимания заказчиком требований. Как уже говорилось выше, в момент начала работы над ТЗ вы можете слабо себе представлять, какую именно систему вы хотите создать. В качестве исходных данных у вас могут быть разрозненные, часто противоречащие друг другу запросы от подразделений, заинтересованных в создании новой системы. Хорошо, если вашей ИТ-службе удалось структурировать их, разрешить противоречия и, тем самым, подготовиться к общению с подрядчиком. Если же нет, то лучший вариант – это сначала разработать очень общее ТЗ, крупными мазками описывающее видение системы, перечислить необходимые модули (подсистемы), не углубляясь в подробности их функционирования, и далее совместно с исполнителем работать над детализацией требований к ним. Последующие версии ТЗ можно оформлять в виде дополнений к первоначальному ТЗ или в виде т.н. «частных технических заданий» (ЧТЗ) на модули решения. Это даст вам время лучше понять что же вы хотите получить в итоге, мобилизовать на работу над проектом подразделения компании, собрать необходимую информацию, освоить основные понятия, если тематика создаваемого решения для вас нова. Также исполнитель сможет лучше познакомиться с деятельностью вашей компании.
Немаловажным моментом является вероятность дрейфа требований. Компании меняются, подстраиваясь под внешние вызовы, причем, часто это происходит достаточно быстро. То, что разработано сегодня может отслужить свое и стать совершенно ненужным завтра в его первоначальном виде. Во избежании ненужных проблем в будущем это сразу надо проговорить с исполнителем и настраиваться на долгосрочное сотрудничество. Грамотный исполнитель в этих условиях может выбрать т.н. спиральную модель разработки ПО, в рамках которой ТЗ, фактически, разрабатывается на каждом новом витке спирали и описывает те изменения, которые должны произойти в следующей версии программного продукта. От написания громоздкого первоначального ТЗ в этом случае можно отказаться, ограничившись ТЗ на первую версию (итерацию).
Ожидаемая длительность проекта, фактически, является одним из факторов дрейфа требований. За долгий срок даже в достаточно неповоротливой компании может многое измениться, например, появиться новое руководство с новым видением. Если же, напротив, проект небольшой и быстрый, то оптимальный вариант – разработать, согласовать и реализовать одно небольшое и достаточно детальное ТЗ.
Значительное число участников проекта, создающих отдельные компоненты решения, требует большей детальности технических заданий, разрабатываемых ими, а также учета еще на этапе ТЗ спецификаций и особенностей реализации соседних модулей. Это поможет в дальнейшем минимизировать риски несостыковки модулей и, соответственно, избежать ненужных психологических и материальных затрат на переделку.
Сложность задачи также оказывает влияние на подход к написанию ТЗ. Увы, задача может быть слишком сложной не только для заказчика, но и для исполнителя, который, казалось бы, имеет опыт в создании решений данного класса. Сложность обычно заключается в том, что создаваемое решение не является типовым и никто из участников проекта не может заранее предсказать результат его внедрения и использования в бизнесе. В этом случае очень важно грамотно разбить проект на этапы (шаги), подразумевая то, что каждый следующий шаг будет корректироваться по результатам, достигнутым на предыдущих. Соответственно и техническое задание будет разрабатываться в начале каждого этапа, опираясь на опыт предыдущего.
Компании работают в реальной среде и часто им приходится иметь дело с новыми партнерами, с которыми ранее они не работали. Это же относится и к разработчикам ИТ-решений. Конечно, хорошо иметь исполнителя, который отлично знает все детали вашего бизнеса, понимает вас с полуслова и в котором вы уверены на все 100% (в этом случае от разработки ТЗ, вообще, можно отказаться), но в реальности это может оказаться совершенно неизвестная вам компания. В таком случае, конечно же, целесообразно начинать сотрудничество с небольших, по-возможности, проектов и с четких и детальных формулировок требований, указанных в ТЗ.
Степень детальности ТЗ и разнесенность во времени его разработки, конечно же, не являются единственными моментами, важными для заказчика. Перед началом разработки ТЗ очень рекомендую определиться с его структурой, фактически, составить страницы с его содержанием, перечнем пунктов и подпунктов до начала работ по ТЗ, а не в процессе или после. При этом и вы и исполнитель договоритесь о том какие вопросы должны быть рассмотрены на данном этапе. Вы будете хорошо понимать, что получите в итоге, а исполнитель будет понимать, что вы от него ждете. Не смотря на кажущуюся простоту, это делается не всегда, даже для крупных и сложных проектов. В итоге ТЗ может получиться совершенно непотребным для дальнейшей работы.
Как известно, существует множество методологий разработки программного обеспечения, отличающихся в числе прочего разной степенью формальности проектной документации. Тем не менее, ТЗ в явном или неявном виде присутствует в любой из них. При этом шаблоны этого документа могут существенно различаться для различных компаний и процессов разработки ПО. Будущий разработчик вашей системы может навязывать вам принятые у него шаблоны ТЗ, но в данном случае важно понимать, что, во-первых, ТЗ является важнейшим инструментом не только для исполнителя, но и для заказчика, который также имеет полное право определять его структуру. И, во-вторых, здравый смысл и основное назначение ТЗ, состоящее в формировании общего видения программного продукта заказчиком и исполнителем, не отменяет ни одна из методологий разработки.
В настоящее время в РФ действует ГОСТ 34.602-89 «Техническое задание на создание автоматизируемой системы», который, не смотря на 89-й год своего создания, неплохо отражает общую структуру ТЗ. Тем не менее, для многих случаев, он является недостаточно детальным и хорошо описывающим специфику разработки современных программных продуктов.
По своему опыту могу порекомендовать обратить внимание исполнителя на необходимость рассмотрения в ТЗ в числе прочих следующих вопросов:
Категории (роли) пользователей, работающих с системой – перечислить роли и кратко описать каким должностям из каких подразделений они соответствуют.
Функционал системы – составить иерархическую структуру, в которой на верхнем уровне перечислены крупные модули (подсистемы), далее детализируемые до более мелких функциональных блоков и даже отдельных функций.
Модель использования системы – сопоставить категории пользователей системы и используемые ими функциональные блоки, обозначенные выше.
Сценарии использования системы при выполнении основных бизнес-процессов – наложить видение решения на реальные процессы, описать на каких этапах и каким образом оно будет использоваться. Не пожалейте времени на то, чтобы совместно с исполнителем наглядно схематически разрисовать сценарии хотя бы по основным бизнес-процессам и согласовать их с заинтересованными лицами.
Прототипы пользовательского интерфейса – схематически изобразить, например, при помощи Microsoft Visio как будут выглядеть основные формы вашего будущего ПО.
Логическая модель данных – изобразить основные сущности предметной области и взаимосвязи между ними. Это позволит вам и исполнителю разговаривать на одном языке с использованием общей терминологии.
Источники данных и взаимодействие с другими системами – описать откуда будут загружаться первоначальные данные при внедрении системы и из каких внешних источников они будут поступать впоследствии.
К рассмотрению этих вопросов в ТЗ стоит подходить «без фанатизма» с учетом возможной неопределенности требований, описанной выше. Детальную их проработку можно оставить на более поздние этапы создания системы, но если вы хотя бы в общих чертах остановитесь на них при разработке ТЗ, то заставите исполнителя и себя лучше подумать над решением, которое пока еще существует только на бумаге и переделка которого пока еще не сопряжена с глобальными финансовыми и временными затратами.
В заключении хотелось бы отметить, что по моему опыту самое лучшее ТЗ – это ТЗ написанное самим заказчиком или при самом активном участии заказчика, т.к. никто лучше сотрудников вашей компании не знает ваших потребностей, деталей работы и далеко не всегда это удается выяснить на интервью. Конечно, для этого необходимо иметь в штате достаточно квалифицированных ИТ-специалистов или воспользоваться услугами ИТ-консультанта. Полученное ТЗ можно использовать в составе тендерной документации для того, чтобы дать большому количеству потенциальных подрядчиков четкое понимание требуемого результата и получить от них предложения.
Еще одно преимущество ТЗ разработанного собственными силами в том, что оно будет отражать исключительно ваши потребности, а не ограничения используемых исполнителем технологических платформ и имеющихся у него наработок для повторного использования. Конечно, исполнителю может потребоваться провести дополнительное обследование и разработать собственную проектную документацию, но все эти документы должны будут соответствовать требованиям в разработанном вами ТЗ. Если же какие-то из ваших требований окажутся нереализуемыми для конкретного исполнителя, то вы непременно об этом узнаете и сможете принять соответствующие решения.
Надо сказать, что у каждой из этих заинтересованных сторон свои требования и свое видение того, каким должно быть «хорошо написанное ТЗ». Например, у заказчика и исполнителя могут быть совершенно противоположные мнения на этот счет. Исполнитель может быть заинтересован в максимально подробном ТЗ для того, чтобы максимально формализовать свои обязательства по функционалу создаваемого решения. При этом заказчик, который точно не определился с параметрами будущей системы или у которого «ветер в голове», может требовать более общих формулировок, описания системы крупными мазками для того, чтобы потом попытаться включить в рамки оговоренного бюджета новые требования. Конечно же, при другом «менталитете» заказчика и исполнителя все может быть с точностью до наоборот. Сейчас мне хотелось бы остановиться именно на разработке ТЗ с точки зрения его заказчика, рассмотрев возможные ситуации, цели и тактики поведения.
Для начала определимся с тем, какие факторы влияют на разработку ТЗ. Прежде всего, это степень понимания заказчиком требований. Как уже говорилось выше, в момент начала работы над ТЗ вы можете слабо себе представлять, какую именно систему вы хотите создать. В качестве исходных данных у вас могут быть разрозненные, часто противоречащие друг другу запросы от подразделений, заинтересованных в создании новой системы. Хорошо, если вашей ИТ-службе удалось структурировать их, разрешить противоречия и, тем самым, подготовиться к общению с подрядчиком. Если же нет, то лучший вариант – это сначала разработать очень общее ТЗ, крупными мазками описывающее видение системы, перечислить необходимые модули (подсистемы), не углубляясь в подробности их функционирования, и далее совместно с исполнителем работать над детализацией требований к ним. Последующие версии ТЗ можно оформлять в виде дополнений к первоначальному ТЗ или в виде т.н. «частных технических заданий» (ЧТЗ) на модули решения. Это даст вам время лучше понять что же вы хотите получить в итоге, мобилизовать на работу над проектом подразделения компании, собрать необходимую информацию, освоить основные понятия, если тематика создаваемого решения для вас нова. Также исполнитель сможет лучше познакомиться с деятельностью вашей компании.
Немаловажным моментом является вероятность дрейфа требований. Компании меняются, подстраиваясь под внешние вызовы, причем, часто это происходит достаточно быстро. То, что разработано сегодня может отслужить свое и стать совершенно ненужным завтра в его первоначальном виде. Во избежании ненужных проблем в будущем это сразу надо проговорить с исполнителем и настраиваться на долгосрочное сотрудничество. Грамотный исполнитель в этих условиях может выбрать т.н. спиральную модель разработки ПО, в рамках которой ТЗ, фактически, разрабатывается на каждом новом витке спирали и описывает те изменения, которые должны произойти в следующей версии программного продукта. От написания громоздкого первоначального ТЗ в этом случае можно отказаться, ограничившись ТЗ на первую версию (итерацию).
Ожидаемая длительность проекта, фактически, является одним из факторов дрейфа требований. За долгий срок даже в достаточно неповоротливой компании может многое измениться, например, появиться новое руководство с новым видением. Если же, напротив, проект небольшой и быстрый, то оптимальный вариант – разработать, согласовать и реализовать одно небольшое и достаточно детальное ТЗ.
Значительное число участников проекта, создающих отдельные компоненты решения, требует большей детальности технических заданий, разрабатываемых ими, а также учета еще на этапе ТЗ спецификаций и особенностей реализации соседних модулей. Это поможет в дальнейшем минимизировать риски несостыковки модулей и, соответственно, избежать ненужных психологических и материальных затрат на переделку.
Сложность задачи также оказывает влияние на подход к написанию ТЗ. Увы, задача может быть слишком сложной не только для заказчика, но и для исполнителя, который, казалось бы, имеет опыт в создании решений данного класса. Сложность обычно заключается в том, что создаваемое решение не является типовым и никто из участников проекта не может заранее предсказать результат его внедрения и использования в бизнесе. В этом случае очень важно грамотно разбить проект на этапы (шаги), подразумевая то, что каждый следующий шаг будет корректироваться по результатам, достигнутым на предыдущих. Соответственно и техническое задание будет разрабатываться в начале каждого этапа, опираясь на опыт предыдущего.
Компании работают в реальной среде и часто им приходится иметь дело с новыми партнерами, с которыми ранее они не работали. Это же относится и к разработчикам ИТ-решений. Конечно, хорошо иметь исполнителя, который отлично знает все детали вашего бизнеса, понимает вас с полуслова и в котором вы уверены на все 100% (в этом случае от разработки ТЗ, вообще, можно отказаться), но в реальности это может оказаться совершенно неизвестная вам компания. В таком случае, конечно же, целесообразно начинать сотрудничество с небольших, по-возможности, проектов и с четких и детальных формулировок требований, указанных в ТЗ.
Степень детальности ТЗ и разнесенность во времени его разработки, конечно же, не являются единственными моментами, важными для заказчика. Перед началом разработки ТЗ очень рекомендую определиться с его структурой, фактически, составить страницы с его содержанием, перечнем пунктов и подпунктов до начала работ по ТЗ, а не в процессе или после. При этом и вы и исполнитель договоритесь о том какие вопросы должны быть рассмотрены на данном этапе. Вы будете хорошо понимать, что получите в итоге, а исполнитель будет понимать, что вы от него ждете. Не смотря на кажущуюся простоту, это делается не всегда, даже для крупных и сложных проектов. В итоге ТЗ может получиться совершенно непотребным для дальнейшей работы.
Как известно, существует множество методологий разработки программного обеспечения, отличающихся в числе прочего разной степенью формальности проектной документации. Тем не менее, ТЗ в явном или неявном виде присутствует в любой из них. При этом шаблоны этого документа могут существенно различаться для различных компаний и процессов разработки ПО. Будущий разработчик вашей системы может навязывать вам принятые у него шаблоны ТЗ, но в данном случае важно понимать, что, во-первых, ТЗ является важнейшим инструментом не только для исполнителя, но и для заказчика, который также имеет полное право определять его структуру. И, во-вторых, здравый смысл и основное назначение ТЗ, состоящее в формировании общего видения программного продукта заказчиком и исполнителем, не отменяет ни одна из методологий разработки.
В настоящее время в РФ действует ГОСТ 34.602-89 «Техническое задание на создание автоматизируемой системы», который, не смотря на 89-й год своего создания, неплохо отражает общую структуру ТЗ. Тем не менее, для многих случаев, он является недостаточно детальным и хорошо описывающим специфику разработки современных программных продуктов.
По своему опыту могу порекомендовать обратить внимание исполнителя на необходимость рассмотрения в ТЗ в числе прочих следующих вопросов:
Категории (роли) пользователей, работающих с системой – перечислить роли и кратко описать каким должностям из каких подразделений они соответствуют.
Функционал системы – составить иерархическую структуру, в которой на верхнем уровне перечислены крупные модули (подсистемы), далее детализируемые до более мелких функциональных блоков и даже отдельных функций.
Модель использования системы – сопоставить категории пользователей системы и используемые ими функциональные блоки, обозначенные выше.
Сценарии использования системы при выполнении основных бизнес-процессов – наложить видение решения на реальные процессы, описать на каких этапах и каким образом оно будет использоваться. Не пожалейте времени на то, чтобы совместно с исполнителем наглядно схематически разрисовать сценарии хотя бы по основным бизнес-процессам и согласовать их с заинтересованными лицами.
Прототипы пользовательского интерфейса – схематически изобразить, например, при помощи Microsoft Visio как будут выглядеть основные формы вашего будущего ПО.
Логическая модель данных – изобразить основные сущности предметной области и взаимосвязи между ними. Это позволит вам и исполнителю разговаривать на одном языке с использованием общей терминологии.
Источники данных и взаимодействие с другими системами – описать откуда будут загружаться первоначальные данные при внедрении системы и из каких внешних источников они будут поступать впоследствии.
К рассмотрению этих вопросов в ТЗ стоит подходить «без фанатизма» с учетом возможной неопределенности требований, описанной выше. Детальную их проработку можно оставить на более поздние этапы создания системы, но если вы хотя бы в общих чертах остановитесь на них при разработке ТЗ, то заставите исполнителя и себя лучше подумать над решением, которое пока еще существует только на бумаге и переделка которого пока еще не сопряжена с глобальными финансовыми и временными затратами.
В заключении хотелось бы отметить, что по моему опыту самое лучшее ТЗ – это ТЗ написанное самим заказчиком или при самом активном участии заказчика, т.к. никто лучше сотрудников вашей компании не знает ваших потребностей, деталей работы и далеко не всегда это удается выяснить на интервью. Конечно, для этого необходимо иметь в штате достаточно квалифицированных ИТ-специалистов или воспользоваться услугами ИТ-консультанта. Полученное ТЗ можно использовать в составе тендерной документации для того, чтобы дать большому количеству потенциальных подрядчиков четкое понимание требуемого результата и получить от них предложения.
Еще одно преимущество ТЗ разработанного собственными силами в том, что оно будет отражать исключительно ваши потребности, а не ограничения используемых исполнителем технологических платформ и имеющихся у него наработок для повторного использования. Конечно, исполнителю может потребоваться провести дополнительное обследование и разработать собственную проектную документацию, но все эти документы должны будут соответствовать требованиям в разработанном вами ТЗ. Если же какие-то из ваших требований окажутся нереализуемыми для конкретного исполнителя, то вы непременно об этом узнаете и сможете принять соответствующие решения.
Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.
Лучшее за 24 часа ↓
Похожие посты ↓
Аналитика и учет телефонных звонков 21.02.2012
Бизнес команды. Мысли обычного инженера 18.01.2012
Прямой эфир ↓
Компания дня 
Q&A ↓
О, работа! ↓
Ближайшие события
Original Page: http://habrahabr.ru/post/149810/#habracut
Sent from my iPad
пятница, 17 августа 2012 г.
IMPORTANT: Remit-To Address Change For Canadian Customers
From: <WebExAR@cisco.com>
Date: 17 August, 2012 11:00:43 AM EDT
To: videoconf_admin@compnet.ru
Subject: IMPORTANT: Remit-To Address Change For Canadian Customers
Reply-To: <WebExAR@cisco.com>
Lockbox email
Tax ID# 77-0059951 IMPORTANT REMIT-TO ADDRESS CHANGE CANADIAN CUSTOMERS Dear Cisco WebEx LLC Customer:
Effective immediately, please note that our lockbox address has been changed.
Thank you in advance for adjusting your records and remittances accordingly.
We apologize for this inconvenience.
CAD Checks:
Cisco WebEx, LLC
c/o 912500
PO Box 4090, Stn A
Toronto, Ontario M5W 0E9USD Checks:
Cisco WebEx, LLC
c/o 912501
PO Box 4090, Stn A
Toronto, Ontario M5W 0E9There is no change to wire instructions. Please include invoice number(s) on wire detail.
Thank you,
Cisco WebEx, LLC
Finance Department
E-Mail: WebExAR@cisco.com
Phone: 1-866-399-3239
© 2012 Cisco and/or its affiliates. All rights reserved.
Cisco WebEx LLC, 3979 Freedom Circle, Santa Clara, CA 95054.
This email was sent to: videoconf_admin@compnet.ru
If you do not wish to receive marketing messages from WebEx, please click here.
WebEx respects your privacy: http://www.webex.com/webex_privacy.html
-WEBEX:enUS: EmM+4KtO9oUqOO4IC9BkF4-
четверг, 19 июля 2012 г.
A hosted A2Billing server is an ideal way to start up your calling card business without the capital expense of hardware and software licenses
суббота, 9 июня 2012 г.
Cisco WebEx: Patch being deployed on Thu Jun 21, 2012
From: "Cisco WebEx Support Services" <Gss_Opt_Out@webex.com>
Date: 8 June, 2012 6:07:23 PM EDT
To: videoconf_admin@compnet.ru
Subject: Cisco WebEx: Patch being deployed on Thu Jun 21, 2012
Dear Oleg Ivashchenko,
Cisco WebEx is sending this message to key business contacts at http://compnet-vcs.webex.com.
On Thu Jun 21, 2012 between 7pm and 11:59pm PDT (GMT-7), Cisco will be applying a Service Pack to the following WebEx services:
* Meeting Center
* Event Center
* Training Center
* Support Center
* Sales Center
This Service Pack includes the following:
* Customers can now select Nigeria when registering for an event in Event Center
Please note:
* During this maintenance period, access to your primary Cisco WebEx website (https://compnet-vcs.webex.com) will be interrupted. All users and visitors will be redirected to the secondary system. While on the secondary system, all Cisco WebEx services will be functioning properly.
* After we have applied the patch to your site, a New Client will automatically be offered the first time users enter a meeting. The installation of the New Client is automatic and browser restart is not required.
If your are experiencing interruptions with any Cisco WebEx services, while on the secondary system, please contact Cisco WebEx Global Support Services so that a Technical Support agent can assist you in resolving the issue.
Cisco WebEx Global Support Services can be reached through our support site at http://support.webex.com/support/support-overview.html or by phone at +1-866-229-3239 or +1-408-435-7088.
If you are located outside the US please go to the following link http://support.webex.com/support/phone-numbers.html for local support numbers.
Sincerely,
Cisco WebEx Customer Services
Cisco Systems, Inc.
-----------------------------------------------------------------------
HOW TO UNSUBSCRIBE
To remove your email address from our database, please REPLY to this message and type "UNSUBSCRIBE" in the subject line. Please include our original message in your reply so we may more accurately process your request.
(WebEx Corp Support Team - compnet-vcs.webex.com - videoconf_admin@compnet.ru )
понедельник, 12 декабря 2011 г.
Building Your Web Practice around Google Apps
From: "Google Apps" <abare@google.com>
Subject: Building Your Web Practice around Google Apps
Date: 12 December, 2011 8:39:00 AM GMT+04:00
Reply-To: abare@google.com
This month, we are offering a new webinar, focused on empowering you to enhance your customer relationships. We are also excited to introduce you to a new support portal, easily accessible through your Reseller Tools console.
See other webinars, resources, and product updates below.
Michael Abare
Google Apps Channel Manager
"Building Your Web Practice" webinar
The Google Apps suite of messaging and collaboration tools is helping millions of businesses to communicate and share information. This has created growth opportunities for MSPs, VARs, IT service providers, systems integrators, and freelance consultants. Please join us for this live webinar to learn how the Google Apps Reseller program empowers you to not only retain control of your customer relationships, but to enhance them.
Register: Wednesday, 12/14/2011 at 11:00 pm PT / 2:00pm ET
What's new in Google Apps
These webinars discuss the new features of Google Apps for Business. This webinar series is delivered monthly. See the presentations from past What's New sessions.
Register: Wednesday, 1/11/2012 at 12:00 pm PT / 3:00 pm ET
Register: Friday, 1/13/2012 at 9:00am GMT+1:00 / 5:00 pm JT
To see a full list of upcoming events, visit the Google Apps Partner Calendar.Archives of the past trainings and webinars can be found on the Reseller Resource Site.
Improved Reseller Support Portal
We are also excited to provide you with an improved reseller support portal, designed to help you have more control over and visibility into the support cases submitted to Google on behalf of your customers. Starting next week, you can access the new support portal in the "Resources for resellers" section of your Reseller Tools or click here:https://www.google.com/a/cpanel/is-alliance.net/ResellerSupport
Connect with complementary software vendors
It's been about a month since the inaugural gSocial, an event run for Google Apps partners, by Google Apps partners. To help cultivate the relationships and conversations you already have or have just started with Apps Marketplace vendors, you can refer to this new resourceto discover existing partner programs of other software vendors. In addition, create a +Pagefor your business, check out the Google Apps reseller circle, and connect with Marketplace vendors in the ISV circle.
24x7 Phone Support
Last month, we opened up 24x7 phone support for all issues affecting the core Google Apps for Business services, adding to our web-based support portal, online help forums, and online help center.
Google Atmosphere 2011 videos
Last month, Google live streamed the keynotes at Google Atmosphere. The presentations are now available for viewing on the Atmosphere 2011 YouTube channel. Learn how successful businesses are using the cloud and collaboration to develop innovative solutions to today's business challenges.
Google Enterprise VP Amit Singh talks about Google's partner strategy
Last week, Talkin' Cloud had a chance to sit down with Google Enterprise VP Amit Singh atCloudBeat 2011 to discuss Google's partner strategy. During the chat, Amit emphasizes that our partner strategy is a "top-three" concern for 2012. Google relies on partners like you to scale, and we're working on new ways to make sure that Google never competes with you.Read the article.
Adding Value with Google Apps Script
In this webinar, Saurabh Gupta, Developer Relations engineer, shares how Google Apps Script can help Google Apps partners build custom functionality, automate business processes, and bring additional value to customers. View the recording.
Go
j
Google Apps New Look updates
Google's visual refresh has been rolling out with the most recent launch being the New Look for Gmail. Many of you invest in and build your business around change management and user training, so we encourage you to switch your customers' domains to the new look using the one-time switch in the control panel and control the timing of when they see the new look. For training resources, email templates, customizable presentations and up-to-date information to help communicate the changes, go to the What's New site and the FAQ on the reseller resource site.
Increased Mobile Device Management options
You can now define mobile policies such as password requirements and roaming sync preferences on a granular basis by user group. Administrators also have the ability to see the mobile productivity within their organizations, complete with trends and analytics. Read more in this blog post.
Browse Google Apps Directory in Gmail
Gmail users can browse the entire Google Apps directory for their domain from within Contacts without having to search. This is especially useful when a user doesn't know the exact name or spelling of the person they're looking for. Just click "Directory" in the left sidebar from within Contacts in Gmail to get started. Here's a link to the help article for more information.
See a complete list of updates from recent weeks.
If you no longer wish to receive these emails, click on the following link: Unsubscribe
Подписаться на:
Сообщения (Atom)
комментарии (0)