Войти
Регистрация
1
Для успешного развития ИТ проектов, а именно проектов в рамках Программного Обеспечения, на мой взгляд должен быть минимальный набор определенных кадров, которые как органы человека, будут выполнять каждый свой функционал. А в гармонии все это превратиться в настоящий живой организм который способен достичь определенных целей.
Итак, прежде чем что-то написать, нужно определиться с тем, что именно будем писать. То есть тут должны быть идейные вдохновители или генераторы идей. Но тут важно понимать, что в зависимости от области разработки, эти люди должны хорошо знать эту область. Если разрабатывается программа для автоматизации банковских бизнес процессов, человек должен прекрасно понимать эти бизнес процессы и уметь грамотно излагать все тонкости что бы все было ясно, что же мы хотим сделать, что должно получиться на финише, и какие подводные грабли могут при этом всплыть. Если быть более кратким, нужны так называемые Аналитики. Которые понимаю область, в которую мы вклиниваем свое ПО.
Далее, должны быть постановщики задач. Это тонкая грань между аналитиком и тем кто понимает общие принципы построения программ. Возможно это даже будет один человек. Одни и те же люди. Которые смогут общую идею, грамотно изложить на бумаге, в виде технического задания, со всевозможными пояснениями, которые программист возьмет за основу и без лишних вопросов сможет понять что именно ему необходимо делать.
Теперь непосредственно о программистах.
Понятное дело что для большого проекта одним программистом не обойтись. Тем более что уровни программистов бывают самые разные, из этого и стоит исходит.
Необходимо подобрать команду таким образом, что бы был хотя бы один человек, который умеет глобально мыслить. И который сможешь видеть ситуацию в целом, понимать постановщиков задач, где нужно поправлять постановщиков так что бы программа не получилась корявой. Который сможет спроектировать архитектуру проекта в целом, и при этом сможет её разбить на отдельные участки таким образом, что бы программисты исполнители могли с чего-то начать, и выполняя задачу за задачей потихоньку приближаться к конечному результату. Причем не так что сначала построили крышу, а потом надо её поднимать на дом, а начиная именно с фундамента, и заканчивая черепицей, образно выражаясь.
Здесь вообще существует целый ряд нюансов.
На мой взгляд нужно определить такое понятие как Нулевая точка отсчета.
То есть, каждому из программистов очень важно влить в сознание, те понятия, которые будут всплывать в проекте. Понятное дело что самое важное - это то что бы главный программист понимал все это. Если понимает хотя бы он, то уже он остальным сможет это объяснить.
Так же это важно потому, что лучше всего программу проектировать на самом начальном этапе таким образом, что бы не приходилось потом уже когда все почти готово, в панике переделывать всю центральную структуру программы. Это на самом деле важный момент - проектирование проекта с самых начал. Подготовка структуры таким образом, что бы в дальнейшем доработка проекта сводилась к минимальным трудозатратам и временным срокам. И главное что бы мелкая доработка не приводила к появлению новых ошибок. А такое часто бывает когда все разрабатывается в кратчайшие сроки и остаются всякие костыли заплатки. Стоит убрать один костыль, как рушится вся система. Это печально когда такое происходит. И что важно - экономически не выгодно.
Из этого следует что важно с самого начала правильно выбрать инструменты для разработки, платформу, архитектуру системы и все свойства и методы расширяемости этой архитектуры.
И как я говорил выше, программистам можно устроить недельный тренинг, отправить на курсы, но важно что бы они понимали что делают. И на что направлен их проект.
Конечно когда нет другого выбора, программисты хорошо справляются с тестированием того что они сделали, но поверьте моему опыту, большая часть ошибок и косяков, приходит в письмах от клиентов. И уж поверьте в этом приятного мало. Это как минимум позор компании, когда клиенты сталкиваются с глючным софтом, они крайне недовольны. Ведь они ни в чем ни виноваты, они заплатили деньги, они все сделали правильно, а программа не работает. или работает но выдает ошибочные результаты. А какого им когда из-за этой ошибки они вынуждены подводить своих собственных клиентов? Каждый наверное из Вас сталкивался с ситуацией, когда стоит большая очередь, в ЦОНе или в банке. Всем срочно что-то нужно. А тут бац, и вам говорят "Извините но у нас компьютеры зависли, сегодня больше не работаем", какого ваше чувство в сей момент?
Из выше описанного следует что очень Важную роль в производстве программного обеспечения играет Тестирование. Понятное дело что и программистов можно заставить оттестировать программу от и до. Но это не всегда получится на 100% исключить ошибочные ситуации. Лучше всего для этого подходят люди которые не писали эту программу. Которые не боятся лишний раз нажать не ту кнопку, не в подходящий момент. Но и важно что бы эти люди сами были либо программистами, либо имели представление о процессе написания программы. И они должны уметь грамотно отлавливать ошибки, и прежде чем отправить эти ошибки программистам, грамотно описать, что они делали, после каких действий ошибка возникает, то есть сценарий воспроизведения ошибки. И возможно даже какие-то мысли о том, почему так случается. Так же на этом этапе тестирования в идеале нужно оценить качество удобства пользовательского интерфейса программы. На сколько удобно расположены элементы управления, и на сколько удобно пользоваться программой. Вносить предложения по оптимизации и удобству.
После того как техническое тестирование программы завершено, важно проверит на сколько правильно работает логическая часть программы. А именно - расчеты, последовательности и т.п. Тут в дело снова вмешиваются Аналитики. Они знают бизнес процесс, соответственно могут с легкостью проверить, правильно ли программа делает расчет, на сколько логически правильно устроена программа, что сначала нужно создать такой документ, и лишь только потом другой. Здесь они проверят, на сколько удобно работать с программой. И так же могут высказать свои пожелания на предмет пользовательского интерфейса. На сколько он удобен.
Лишь после того как программа, или определенная версия программы пройдет такой процесс обкатки, а именно: Автоматическое тестирование программистами, Техническое ручное тестирование отделом тестирования и тестирование аналитическим отделом, продукт можно отдавать клиентам. Но даже при такой тщательной подготовки программы, могут возникнуть сложности на стороне клиентов. Для этого нужно что? Отдел технической поддержки. Отдел куда всегда могут позвонить клиенты с вопросами, как и почему. Что за ошибка.
Причем тут стоит отметить что клиенты могут позвонить или написать, с двумя типами вопросов.
1. Вопрос: А как это работает?
2. Вопрос: А почему у меня программа выдает ошибку?
Следовательно должны быть специалисты готовые по телефону проинструктировать пользователей по вопросам, как это работает.
А так же должны быть специалисты которые могут выяснить что за проблема возникла у клиентов и как её решить. Решить самостоятельно либо привлечь программистов и тестировщиков к этому делу, что бы в конечном итоге либо найти решение на стороне клиентов, либо выпустить обновление, которое решит проблему.
Так же для того что бы меньше было вопросов по части " А как это работает?" программа мало того что должна быть очень простой и понятной, она ещё должна быть и грамотно задокументированной. То есть должно быть пользовательское руководство, подробно описывающее то, как с этой программой работать. И даже описывать возможные технические проблемы, что бы технические специалисты на стороне клиентов, могли руководствуясь этим описанием, правильно инсталлировать и настроить продукт. Это значительно сократит количество звонков, а если и не количеств звонков, то можно будет смело сказать "Откройте руководство на таком то разделе, там подробно, с картинками описан Ваш случай. Если что-то не получится по сценарию руководства, тогда перезвоните, будем решать. Либо везите компьютер.
Кто должен писать руководство?
Думаю будет не целесообразно создавать специальный отдел который будет только что и делать как писать руководство. Не выгодно, ведь это не каждый день нужно делать. Считаю правильным экономическую часть возложить на аналитиков, а техническую часть на тестировщиков. Так как и те и другие, имеют возможность выделить на это время. К примеру когда все уже оттестировано и понятно, а программисты трудятся над очередной версией, тестировщики и аналитики могут спокойно писать пользовательское руководство.
Таким образом мы приходим к тому, что в компании для правильно поставленного процесса развития ПО, должны существовать следующие отделы:
- Отдел разработки и поддержки ПО.
- Отдел технического тестирования ПО.
- Отдел аналитиков и постановщиков задач
- Отдел технической поддержки
- Отдел тематического консультирования.
В следующем посту чуть подробнее рассмотрю моменты организации труда и процессов развития проектов.
Итак, прежде чем что-то написать, нужно определиться с тем, что именно будем писать. То есть тут должны быть идейные вдохновители или генераторы идей. Но тут важно понимать, что в зависимости от области разработки, эти люди должны хорошо знать эту область. Если разрабатывается программа для автоматизации банковских бизнес процессов, человек должен прекрасно понимать эти бизнес процессы и уметь грамотно излагать все тонкости что бы все было ясно, что же мы хотим сделать, что должно получиться на финише, и какие подводные грабли могут при этом всплыть. Если быть более кратким, нужны так называемые Аналитики. Которые понимаю область, в которую мы вклиниваем свое ПО.
Далее, должны быть постановщики задач. Это тонкая грань между аналитиком и тем кто понимает общие принципы построения программ. Возможно это даже будет один человек. Одни и те же люди. Которые смогут общую идею, грамотно изложить на бумаге, в виде технического задания, со всевозможными пояснениями, которые программист возьмет за основу и без лишних вопросов сможет понять что именно ему необходимо делать.
Теперь непосредственно о программистах.
Понятное дело что для большого проекта одним программистом не обойтись. Тем более что уровни программистов бывают самые разные, из этого и стоит исходит.
Необходимо подобрать команду таким образом, что бы был хотя бы один человек, который умеет глобально мыслить. И который сможешь видеть ситуацию в целом, понимать постановщиков задач, где нужно поправлять постановщиков так что бы программа не получилась корявой. Который сможет спроектировать архитектуру проекта в целом, и при этом сможет её разбить на отдельные участки таким образом, что бы программисты исполнители могли с чего-то начать, и выполняя задачу за задачей потихоньку приближаться к конечному результату. Причем не так что сначала построили крышу, а потом надо её поднимать на дом, а начиная именно с фундамента, и заканчивая черепицей, образно выражаясь.
Здесь вообще существует целый ряд нюансов.
На мой взгляд нужно определить такое понятие как Нулевая точка отсчета.
То есть, каждому из программистов очень важно влить в сознание, те понятия, которые будут всплывать в проекте. Понятное дело что самое важное - это то что бы главный программист понимал все это. Если понимает хотя бы он, то уже он остальным сможет это объяснить.
Так же это важно потому, что лучше всего программу проектировать на самом начальном этапе таким образом, что бы не приходилось потом уже когда все почти готово, в панике переделывать всю центральную структуру программы. Это на самом деле важный момент - проектирование проекта с самых начал. Подготовка структуры таким образом, что бы в дальнейшем доработка проекта сводилась к минимальным трудозатратам и временным срокам. И главное что бы мелкая доработка не приводила к появлению новых ошибок. А такое часто бывает когда все разрабатывается в кратчайшие сроки и остаются всякие костыли заплатки. Стоит убрать один костыль, как рушится вся система. Это печально когда такое происходит. И что важно - экономически не выгодно.
Из этого следует что важно с самого начала правильно выбрать инструменты для разработки, платформу, архитектуру системы и все свойства и методы расширяемости этой архитектуры.
И как я говорил выше, программистам можно устроить недельный тренинг, отправить на курсы, но важно что бы они понимали что делают. И на что направлен их проект.
Конечно когда нет другого выбора, программисты хорошо справляются с тестированием того что они сделали, но поверьте моему опыту, большая часть ошибок и косяков, приходит в письмах от клиентов. И уж поверьте в этом приятного мало. Это как минимум позор компании, когда клиенты сталкиваются с глючным софтом, они крайне недовольны. Ведь они ни в чем ни виноваты, они заплатили деньги, они все сделали правильно, а программа не работает. или работает но выдает ошибочные результаты. А какого им когда из-за этой ошибки они вынуждены подводить своих собственных клиентов? Каждый наверное из Вас сталкивался с ситуацией, когда стоит большая очередь, в ЦОНе или в банке. Всем срочно что-то нужно. А тут бац, и вам говорят "Извините но у нас компьютеры зависли, сегодня больше не работаем", какого ваше чувство в сей момент?
Из выше описанного следует что очень Важную роль в производстве программного обеспечения играет Тестирование. Понятное дело что и программистов можно заставить оттестировать программу от и до. Но это не всегда получится на 100% исключить ошибочные ситуации. Лучше всего для этого подходят люди которые не писали эту программу. Которые не боятся лишний раз нажать не ту кнопку, не в подходящий момент. Но и важно что бы эти люди сами были либо программистами, либо имели представление о процессе написания программы. И они должны уметь грамотно отлавливать ошибки, и прежде чем отправить эти ошибки программистам, грамотно описать, что они делали, после каких действий ошибка возникает, то есть сценарий воспроизведения ошибки. И возможно даже какие-то мысли о том, почему так случается. Так же на этом этапе тестирования в идеале нужно оценить качество удобства пользовательского интерфейса программы. На сколько удобно расположены элементы управления, и на сколько удобно пользоваться программой. Вносить предложения по оптимизации и удобству.
После того как техническое тестирование программы завершено, важно проверит на сколько правильно работает логическая часть программы. А именно - расчеты, последовательности и т.п. Тут в дело снова вмешиваются Аналитики. Они знают бизнес процесс, соответственно могут с легкостью проверить, правильно ли программа делает расчет, на сколько логически правильно устроена программа, что сначала нужно создать такой документ, и лишь только потом другой. Здесь они проверят, на сколько удобно работать с программой. И так же могут высказать свои пожелания на предмет пользовательского интерфейса. На сколько он удобен.
Лишь после того как программа, или определенная версия программы пройдет такой процесс обкатки, а именно: Автоматическое тестирование программистами, Техническое ручное тестирование отделом тестирования и тестирование аналитическим отделом, продукт можно отдавать клиентам. Но даже при такой тщательной подготовки программы, могут возникнуть сложности на стороне клиентов. Для этого нужно что? Отдел технической поддержки. Отдел куда всегда могут позвонить клиенты с вопросами, как и почему. Что за ошибка.
Причем тут стоит отметить что клиенты могут позвонить или написать, с двумя типами вопросов.
1. Вопрос: А как это работает?
2. Вопрос: А почему у меня программа выдает ошибку?
Следовательно должны быть специалисты готовые по телефону проинструктировать пользователей по вопросам, как это работает.
А так же должны быть специалисты которые могут выяснить что за проблема возникла у клиентов и как её решить. Решить самостоятельно либо привлечь программистов и тестировщиков к этому делу, что бы в конечном итоге либо найти решение на стороне клиентов, либо выпустить обновление, которое решит проблему.
Так же для того что бы меньше было вопросов по части " А как это работает?" программа мало того что должна быть очень простой и понятной, она ещё должна быть и грамотно задокументированной. То есть должно быть пользовательское руководство, подробно описывающее то, как с этой программой работать. И даже описывать возможные технические проблемы, что бы технические специалисты на стороне клиентов, могли руководствуясь этим описанием, правильно инсталлировать и настроить продукт. Это значительно сократит количество звонков, а если и не количеств звонков, то можно будет смело сказать "Откройте руководство на таком то разделе, там подробно, с картинками описан Ваш случай. Если что-то не получится по сценарию руководства, тогда перезвоните, будем решать. Либо везите компьютер.
Кто должен писать руководство?
Думаю будет не целесообразно создавать специальный отдел который будет только что и делать как писать руководство. Не выгодно, ведь это не каждый день нужно делать. Считаю правильным экономическую часть возложить на аналитиков, а техническую часть на тестировщиков. Так как и те и другие, имеют возможность выделить на это время. К примеру когда все уже оттестировано и понятно, а программисты трудятся над очередной версией, тестировщики и аналитики могут спокойно писать пользовательское руководство.
Таким образом мы приходим к тому, что в компании для правильно поставленного процесса развития ПО, должны существовать следующие отделы:
- Отдел разработки и поддержки ПО.
- Отдел технического тестирования ПО.
- Отдел аналитиков и постановщиков задач
- Отдел технической поддержки
- Отдел тематического консультирования.
В следующем посту чуть подробнее рассмотрю моменты организации труда и процессов развития проектов.
