Страницы

четверг, 12 декабря 2013 г.

12 навыков, которые помогут найти причину ошибки, если непонятно, из-за чего она происходит

В работе программиста есть навыки, которые мало где четко и подробно описаны. Обычно каждый специалист постепенно и неосознанно формирует их у себя самостоятельно. Механизмы работы этих навыков также обычно не анализируются, в том числе из-за того, что они используются на подсознательном уровне.


Одним из таких навыков является процесс анализа причин возникновения ошибок, когда невозможно четко определить причину неправильной работы. Или в силу того, что ошибка связана с плохо документированными особенностями самой платформы или по какой-то другой причине мы не можем пробежаться по коду отладчиком и понять весь алгоритм (или не хотим, так как слишком много кода и столько времени тратить просто не рентабельно).
Оценка времени решения проблем в таких областях плохо прогнозируема. Во время исследования можно уйти не в ту сторону и потерять достаточно много времени впустую. Чаще всего это происходит потому, что человек не хочет переключаться на другие направления поиска, а хочет добиться решения именно через выбранное направление, так как не хочет терять то время, которое уже потратил. Или есть обратное явление - человек начинает слишком часто переключается на новые пути решения, не доводя дело до конца. Также, можно зациклиться на одной несущественной мелочи, которая показалась «решаемой», хотя она является всего лишь последствием проблемы.

Давайте попытаемся разобраться и составим примерный алгоритм действий поиска решения. А так же выясним, какие умения помогают эффективно решать такие проблемы.

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

Термин
Сначала хочу пояснить одно понятие употребляемое мной:
Модели работы механизмов - здесь это представление как может работать конкретный механизм внутри платформы с технической стороны. Например, особенности процессора вывода СКД (система компоновки данных), ошибки времени выполнение запросов, отображение управляемых форм.

Для эффективного решения трудноанализируемых проблем нужно:
  • Обширная база моделей работы алгоритмов в голове. Знание моделей позволяет быстро строить гипотезы о работе исследуемого механизма. Что помогает вообще понять где и из-за чего может быть ошибка.
  • Умение видеть проблему максимально широко в любой момент времени. К примеру, не зацикливаться на конкретном решении возникших подпроблем, возможно при другом варианте этих новых проблем и нет.
  • Умение критически оценивать текущее направление поиска. Честно признаваться себе эффективно ли то, что ты сейчас делаешь и может есть другой подход к проблеме?
  • Мотивация на результат. Умение добиваться цели.
  • Развитые аналитические способности, в т. ч. осознанное или интуитивное применение основных инструментов анализа.
 
Тренировка

  1. Постоянное изучение и формирование моделей на основе данных встречаемых задач.
    • При решении задачи важно не просто решить ее, нужно понять, почему она произошла, как работает затрагиваемый внутренний механизм и что еще может произойти.
    • Рекомендуется записывать в некую базу знаний и/или рассказывать кому-то о проблеме и ее решении. При подобном описании становятся лучше видны пробелы в знаниях, а так же опыт прочнее закрепляется в голове. Дополнительно, если вы своим опытом кому-то помогли, то этот опыт лучше «индексируется» в голове по ключевым словам проблемы.
  2. Изучение любой информации о внутренней работе типовой функциональности платформы. Изучение особенностей системы.
    • Изучайте любую информацию, которую можно найти о работе внутренних механизмов платформы. В том числе списки ошибок платформы (файлы ErrPlatform_*.htm) и темы форумов про них же.
    • Дополнительно было бы не лишним изучать общую теорию программирования, работу с памятью, стандартные алгоритмические модели. Это помогает понять, как вообще могли сделать изучаемый механизм.
Для решения любых задач (особенно на этапе выдвижения предположений) помогает опыт в похожих областях. Так что, изучая что-то, вы получается навыки не только исследуемой области, но и косвенно увеличиваете шансы быстро решить проблемы в области с совпадающей логикой. (Правда возможно и то, что вам какой-то опыт наоборот помешает. Но я надеюсь вы умеете рационально оценивать применимость знаний).
  1. Пополнение моделей работы дополнительным чтением выборочных статей. Можно тратить хотя бы полчаса времени в день для чтения статей не по теме рабочих задач.
  2. Развитие аналитических способностей. Например, это можно сделать с помощью логических и дедуктивных игр. Можно поставить такие игры к себе на телефон и решать 1-2 задачки за день. Так же можно решать задачки на анализ ситуации, подобные тем, что ходят по интернету в виде тестов от google для менеджеров продукта. Кроме того, можно начать изучать элементы и инструменты анализа проблем.
  3. Развитие самомотивации. Помогает самоанализ, что же привлекает тебя в твоей работе вообще и искусственное подчеркивание данных аспектов во время приступов лени. Видеть результаты своего труда, например, копить базу записей решенных задач. (Но не забываем, что иногда просто надо временно переключиться на другую задачу или просто дать 5 минут мозгу отдохнуть).
  4. Всегда пытайтесь оценить для себя сколько займет времени завершить задачу по текущему пути поиска решения. Понятно, что это оценка при большом количестве неизвестных будет чаще совсем неправильная и больше на ощущениях. Но если вы начнете хоть как-то оценивать, то вы научитесь как минимум трезво смотреть на текущий процесс и научитесь осознаннее чувствовать перспективность направления дальнейшего поиска.


Подготовка к процессу
  1. Перестать переживать. Есть конечно полезный стресс, но чаще переживания только мешают думать. Так что лучше отключиться от страхов и переживаний типа «А Вася бы это сделал за пять минут», «Я не успею вовремя и все провалю».
  2. Есть просто результат, эффективность, прибыль и полученный по итогам опыт. Что-то одно может перевешивать. Главное, чтобы вы и человек ответственный за затраты понимали риски и возможное соотношение этих показателей. (про переживания советую почитать на Хабре)
  3. Выгрузить все текущие дела из головы, хотя бы на бумагу. Дела имеют привычку ни с того ни с сего всплывать в голове и отвлекать вас. Поэтому запишите их куда-то, чтобы не забыть и мозг успокоиться. Вообще рекомендую посмотреть методику GTD (Getting Things Done).Дать проблеме имя. Сформировать для себя четкое понимание, что за проблему мы решаем. Как это не странно, но непонимание, что мы в итоге исправляем и для чего, наиболее частая проблема затягивания решения.
  4. Определить правильный мотив. Проверить мотивацию на решение. Если мотивация «отработать» до конца дня, то задача вряд ли решиться. Если нет никакой мотивации на решение, то можно создать себе мотивацию самостоятельно. Например, решить для себя, что по итогам вы опубликуете проблему и решение на каком-нибудь известном сайте или поспорить с кем-нибудь, что вы сможете побороть проблему за час.
  5. Определить конечную цель. Надо определить четкие критерии результата, при котором задача будет считаться решенной. А далее уже ориентируясь на цель прокладывать пути поиска решений проблемы.
  6. Таймбоксинг. Если примерное время и вообще возможность решения проблемы не ясны и это демотивирует вас, то можно воспользоваться методом таймбоксинга. Метод заключается в определении для себя периода времени, в котором вы будете решать проблему и будете решать ее с полной самоотдачей. То есть, «Максимально сосредоточенно пытаюсь решить ее 2 часа, а потом переключаюсь на другую задачу». Это, во-первых, помогает проще и быстрее начать решать проблему, так как уменьшает моральное давление (вы как бы только пробуете). Во-вторых, помогает активизироваться, типа «у меня только 2 часа».
Продолжение следует...

среда, 4 сентября 2013 г.

Алгоритм работы с техническим заданием заказчика

Что ни говорите о технической стороне разработки 1С, для успешной реализации проекта этого недостаточно. На общий итог также влияют рабочие коммуникации, которые выстраиваются, начиная с технического задания Заказчика. Как своевременно понять, чего именно хочет Клиент, и избежать подводных рифов на пути к цели? Вниманию разработчиков 1С - опыт «Нэти», одной из ведущих аутсорсинговых IT-компаний России.


4 способа оценить задачу, чтобы не прогадать

1. Разброс оценок «от и до». Применяется, если невозможно дать точную оценку, например, задачи типа обновления сильно измененной конфигурации 1С (когда изменения вносили не мы), некоторые проектные работы, которые завязаны на длительное обсуждение с пользователями в процессе разработки или привлечения третьей стороны.
Разброс помогает определить общий бюджет 1С-задачи. По итогам дается фактическая оценка. Если становиться ясно, что фактические затраты, возможно, выйдут за изначальный промежуток, то это сразу сообщается Клиенту.

2. Неточная оценка, с запасом на изменение не основных частей ТЗ. Используется, если у Заказчика долгое согласование бюджетов внутри фирмы, а Клиенту нужна конкретная стоимость разработки на 1С уже сейчас (без дополнительных затрат).
Также применяется, если существует вероятность некоторых изменений неосновных моментов. Как? Задача оценивается как общая разработка, с запасом (определяется отдельно) на обсуждение и переделку конкретных моментов - по итогам реализации.

3.Оценка с небольшими техническими вопросами. Реализуется, когда, по итогам уточнений, у вас есть четкое и полное описание задачи в терминах пользовательской части системы. 
Сначала уточняется все, кроме несущественных для пользователя моментов реализации (технических и быстро изменяемых). Потом оценивается общая реализация с рисками на сложность разработки, с учетом, например, разных технических способов решения одной и той же проблемы. Указанные риски могут быть нулевые, если вы все это уже реализовывали и у вас есть рабочий пример.

4. Оценка по жестко и полностью прописанному заданию (и бизнес-блок, и часть технической реализации). Используется, когда на стороне заказчика есть свой отдел разработки 1С, со своими стандартами. Как? Уточняется целиком бизнес-логика задания (для чего это нужно пользователю, что в итоге получим и т.д.), анализируется и уточняется техническая архитектура 1С-задачи, предоставленная заказчиком, или предлагается и согласуется наш вариант реализации. Такая работа оценивается максимально точно.


«Метод двойного подхода» при анализе больших и непонятных ТЗ

Техническое задание не всегда написано максимально понятно и последовательно. Особенно часто это встречается в 1С отрасли. Иногда задание просто большое, с путаными взаимосвязями по всему тексту. Как справиться с анализом таких задач, чтобы минимизировать риск появления лишних вопросов и потерю вопросов, связанных с взаимосвязями между разными объектами задания? На самом деле ничего сложного, если читать техническое задание два раза, составляя вопросы при втором подходе.

Первый подход (чтение). Составление общей структуры (технического скелета) задачи, проверка существования используемых объектов, открытие форм и модулей на просмотр объема и сложности кода.
Второй подход (чтение с добавлением вопросов). Уточнения для себя конкретных моментов. Выбор конкретных методов реализации. Составление вопросов по неясным моментам. Доработка идеи структуры общего механизма. Продумывание сложных моментов соединения таблиц, структур регистров.

Итог
Таким образом, после первого анализа задачи (до уточнения вопросов), можно дать разброс оценок или уже готовую оценку, если вопросы незначительны.

Плюсы двойного подхода: 

  • Эффективность при анализе технического задания с неправильной последовательностью описания (только в конце становится понятно, что имели в виду в начале).
  • Как следствие – отсутствие лишних вопросов.
  • При втором подходе, зная общую структуру и идею всей задачи, можно более четко определять конкретную реализацию каких-то блоков, так, чтобы они учитывали общий механизм.
  • Так же знание общей структуры важно и для определения не описанных в техзадании моментов. То есть, при втором подходе вы уже четко увидите и отметите, например, чего не хватает в первом блоке, что используется дальше во втором.


Когда и как подключать к работе эксперта

1. Если вам недостает знаний для анализа или оценки техзадания в какой-то области, то лучше привлечь эксперта. Узнайте, кто в этом разбирается и договоритесь, что вам помогут. Или обращайтесь к руководителю с вопросом поиска эксперта, на правах внешнего консультанта.
2. Хорошо бы фиксировать контакты людей, компетентных в чем-то, чего не знаете вы. При случае можете помочь этим контактом кому-то из ваших коллег.


Как узнать все, что нужно, и не показаться дураком
Основные принципы уточнения заданий


При общении с представителем Заказчика, даже если речь идет о чисто вопросах программирования на 1С, не всегда все максимально удобно и понятно. Поскольку все привыкли работать по-своему, корректные рабочие коммуникации также надо уметь выстраивать. Вот несколько рекомендаций, как правильно общаться с Клиентом на начальном этапе, чтобы в случае возникновения спорных ситуаций можно было легко поднять переписку и восстановить взаимопонимание.

1. Способы задавать вопросы

1.1. Размещайте вопросы в файле ТЗ и пересылайте его уже почтой – это наиболее безопасный и правильный подход (если по почте отвечают быстро или сроки не горят), так как все сразу видно в одном файле. Способ делится на вопросы:

  • В примечаниях (сбоку)
  • Выделенные другим цветом и шрифтом прямо в тексте
  • Методом исправления (Word). Данный файл по итогам прикрепляется к задаче учетной системы (например, JIRA).

1.2 Когда нет отдельного файла ТЗ, фиксируйте вопросы в теле письма . В таком случае размещайте в задаче учетной системы (например, JIRA) все обсуждения. Хотя бы методом «Копировать» - «Вставить» из письма.

1.3.    Избегайте вопросов в скайпе. Переписка в скайпе редко может считаться доказательством договоренностей с консультантом (там можно и отредактировать и удалить текст, сообщения не хранятся на сервере). Сообщение в скайпе забываются или, в связи с отсутствием внешнего сервера хранения сообщений, теряются. Да и просто вы можете попасть на неудобное для консультанта время, и он, бегло прочитав вопрос, неправильно его поймет.

Поэтому все итоговые обсуждения, или выясненные, например, за день вопросы, фиксируйте письмом. Кратко описывайте принятые решения с вступительным текстом, например «Дублирую обсуждение по Skype письмом». Так же опять же тот же текст копируется в учетную систему (например, JIRA) в комментарии к задаче.

1.4.    Переводите в текст вопросы голосом по скайпу или по телефону. При устном общении в любом случае лучше фиксировать договоренности и ответы письмом аналогично предыдущему пункту. Так же опять же тот же текст копируется в учетную систему (например, JIRA) в комментарии к задаче.

1.5.   Собирайте и систематизируйте всю информацию в один файл. По 1.2, 1.3 и 1.4 пунктам лучше копировать получившиеся тексты обсуждений в текст техзадания (для простоты, например, после основного текста). Чтобы всегда можно было одним файлом переслать файл со всей информацией.

2. Принцип задавания вопросов – «90% и сразу»

Старайтесь увидеть неясности и задать вопросы сразу по максимуму. Нахождение всех нестыковок в техзадании достигается тренировкой моделирования в уме технической реализации задачи. В нашей IT-аутсорсинговой компании «Нэти» такие тренировки практикуют многие. Это эффективнее и удобнее, чем спрашивать представителя заказчика по 10 раз в день, попадая на моменты, когда представителя нет на месте (они – люди, и также ходят в туалет, опаздывают, едят и даже болеют).

3.    Методы утончения вопросов

3.1.   Варианты своего понимания вместе с уточняющими вопросами. Если это уместно, (становится ясно при первом общении с консультантом 1С) при непонятной формулировке в техническом задании, можно предлагать в тексте свои варианты понимания задачи. То есть «Имеется в виду, что <то-то и то-то> или все же <то-то>. Если первое, то вопрос такой:  <вопрос>.

3.2. Переспрос – для надежности. Если в ТЗ вроде понятно написано, но вы не уверены, то лучше так и спросить: «Я правильно понял, что <то-то>?».

4.    Отсроченная сила «висящего в ящике письма». Кроме вышеназванных минусов вопросов по скайпу и по телефону, есть и такой, что человек устает говорить и, с легкой руки подсознания, сбрасывает все – то есть забывает, что хотел сказать. Письмо же висит и ждет ответа.

4.1. «Вечером – вопросы, с утра - ответы». Если отправка вопросов по почте затянулась до вечера, то лучше и отправлять письмо прямо вечером, а не затягивать до утра. Тогда с утра на той стороне сразу увидят письмо. Если же вы отсылаете письмо днем, то день к тому времени уже распланирован, и люди могут не найти время.

5. Учитывайте вероятность форс-мажорных обстоятельств. Заносите все ответы и уточнения скайпом, письмом и голосом в комментариях в учетную систему (например, JIRA). При форс-мажорах вы или ваши коллеги смогут  быстро поднять всю информацию.


6 правил точной оценки трудоёмкости задачи

Как свести к минимуму вероятность оценки «от балды»? - корпоративный опыт IT-аутсорсинговой компании «Нэти»

1.    Оценка по методу PERT. В нашей компании разработчики 1С используют оценку по методу PERT. 
Данная оценка выполняется так:
  1. Дробление задачи и оценка по частям. Задача разбивается на небольшие блоки-подзадачи, которые можно максимально точно оценить.
  2. Прогнозы решения задач – по шкале оптимизма. Для каждого блока рассчитывается оптимистичная, реальная и пессимистичная оценка. Если вы не сами себе консультант и не знаете все идеально, то оценки, хоть немного, но будут разными! (не считая задачи типа «добавление реквизита, без добавления на форму»).
  3. Основной расчет. Далее по математическим  формулам вычисляется оценка по выбранной процентной вероятности выполнения задания.(подробнее о расчетах можно почитать, например, здесь http://www.intuit.ru/studies/courses/2194/272/lecture/3693?page=4)


Оптимистичная – это та трудоемкость, которая может получиться, если все будет хорошо. То есть, вы все поняли правильно и внезапных трудностей с реализацией не возникнет.
Реальная – это та трудоемкость, которая по вашему опыту обычно получается: "скорее всего, здесь не все так просто, но я разберусь за такое-то время, плюс обычно возникает еще один вопрос во время реализации, так что плюс время на уточнение".
Пессимистичная – это та трудоемкость, которая может получиться, если все будет плохо. Для примера, если есть момент, который трудно реализовать, то определите, насколько максимум может растянуться реализация. Если у вас почему-то остались вопросы, то учтите, что ответы на них будут самыми печальными.

Для быстрой оценки должен быть уже готовый специальный файл Excel, в котором вбиты все формулы и остается только забить подзадачи и их оценки. Наш шаблон файла оценки состоит из двух страниц:

  • На первой фиксируется затраты на уже проведенный для оценки анализ и показываются  рассчитанные общие цифры по данным второй страницы, также отдельно рассчитывается процент общего тестирования.
  • На второй странице – в таблице вбиваются части задачи и их оценки (оптимистичная, реальная и пессимистичная).

2.    Если блок непонятен и нет возможности его разделить:
2.1.    Привлекаете эксперта, если не можете оценить блок.
2.2.    Если эксперта нет, то об это сообщается руководителю, и задача чаще оценивается с широким разбросом «от» и «до»

3. Примерное структурирование - по пунктам. Блок для оценки - это не целиком объект со всей его функциональностью (если только вы не можете его идеально оценить)! Пункты блоков в оценке - это, например, форма, регламентированное задание, новый регистр, функция, запрос и т.д.

3.1.  Пример. То есть, разработка на 1С отчета с использованием СКД делится на: составление запроса, заполнение параметров из формы отчета, остальная форма, вывод специфики в макете, процесс описания и подключения внешних таблиц, оформление (цвета строк, ширина колонок и т.д.).

3.2. Выделяйте сложные для реализации моменты. Если есть какой-то сложный для вас момент в реализации, то его надо выделить отдельно. Например, заполнение конкретной колонки в отчете. Или это, может быть, например, отдельно анализ чего-то определённого в чужом коде и отдельно разработка по проанализированному функционалу.

4. Почему дробление – ваш друг? Чем больше объекты оценивается без дробления, тем хуже оценка. В 90% случаев это значит, что оценка меньше реальной трудоемкости.

5.  Анализ техзадания тоже включается в оценку! По нашему файлу все, что вы потратили на оценку разработки, вы фиксируете и включаете в поле «Анализ» на первой странице.

6.    Дальше за вас все считают формулы в файле. (Для файла расчета необходимо изначально определить тот процент вероятности выполнения в рамках оценки, который вам нужен).


Как сообщать результаты разработки

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

Что вы должны знать о людях как разработчик

  • Люди по умолчанию не доверяют другим людям.  Поэтому они будут сомневаться, что вы все протестировали, все доделали и вообще сделали то, что нужно.
  • Так же люди разражаются когда что-то не понимают или не находят, особенно когда это что-то простое. А так как человек вообще не склонен винить себя в чем-то, то он подсознательно будет винить вас, как разработчика такого вот не интуитивно понятного интерфейса.


6 результатов разработки, о которых стоит написать Заказчику

1. Если вы при разработке сами приняли какое-то решение (не было консультанта или уточнение было не существенно), то об этом надо написать письмом при сдаче задачи. Например: «при открытии обработки поле Организация автоматически заполняется из настроек пользователя, так как это необходимо для дальнейшего автоматического заполнения».

2. Если вы для своих объектов разработали в конфигурации 1С новый интерфейс или добавили пункт в меню в существующий интерфейс, то об этом надо написать обязательно! Конкретно: куда добавили и что там появится при открытии. Пользователь не должен искать, что и где вы создали. Исключением может быть, только если стояла задача – «создать автопоявляющеюся при запуске кнопку «Сделать все» на весь экран».

3. Если вы добавили дополнительно что-то, что вообще не обговаривалось, то опять же об это надо написать. Например «Дополнительно при проведении документа происходит проверка на заполнение реквизитов <таких-то>».
Заказчику будет приятно, что вы подумали о нем, поэтому пускай дополнительные положительные эмоции появляются стопроцентно и сразу при первом тесте.

4. Если оказалось, что вы досконально не проговорили какой-то функционал, например форму настройки, то надо написать по итогам реализации, что там можно настроить и как.

5. Описание процесса тестирования убережет от негатива. Лучше написать 3-4 предложения, как и что надо сделать для того, чтобы протестировать ваш функционал. Это убережет вас от лишнего, хоть и, возможно, недолгого негатива типа «сходу ничего не понял». А то ведь человек разберется, куда нажимать, а плохое ощущение останется.

6.  Завершайте на мажорной ноте. И главное! Фраза «Если будут вопросы по новому функционалу - пишите. С радостью отвечу» никого еще не убила, но эффект от нее потрясающий – пользователь не нервничает, и поэтому лучше соображает при знакомстве с результатами вашего труда.

Материал также размещен в базе знаний аутсорсинговой IT-компании «Нэти» – специально для разработчиков 1С
Neti - крупное аутсорсинговое предприятие, с огромным опытом разработки как на платформе 1С, так и работы с рядом других корпоративных систем. Среди клиентов - МАИ «Футбольный клуб «Рубин», предприятие «ПАИ» миллиардера А.Семина, входящего в 200-и крупнейших бизнесменов России, «Интелком» и другие ведущие франчайзи-партнеры 1С в России: от Владивостока - до Санкт-Петербурга.
Должный уровень взаимодействия с заказчиком, организацию и качество работ обеспечивают разработчики, 80 % которых имеют высочайшую профессиональную квалификацию (и стаж работы,в среднем, более 7 лет, с опытом участия  в более, чем 10 крупных проектах). В штате компании - разработчики разных платформ: 1С 7.7, 8.2, Dynamics AX, NAV, CRM, SharePoint, .Net. Также программисты с опытом Галактики, Парус, МАХ, Joomla, 1С-Bitrix и других систем. Наличие компетенций в разных системах позволяет решать сложные интеграционные задачи.

Выражаю благодарность за помощь в редактировании статьи Владимиру В. Сыченкову.