The post has been translated automatically. Original language: Russian
Greetings! I am Timur Dragunov. I have been working in the IT field for over 10 years. He started his career as a developer of Internet projects. Later, he joined the team of the Russian PDF Commander editor. In recent years, my colleagues and I have focused on the corporate segment. This part of the market is traditionally considered more profitable than completing projects for ordinary users. In addition, a significant part of potential customers have a demand for alternatives to solutions from large international companies.
However, it was not only these two factors that influenced the change in the direction of work. Corporate clients have stricter requirements and have a request to solve specific tasks. This became a serious challenge for us and helped us find new ways of professional development. I will tell you more about the stages of software development for organizations. This information will be useful if you and your team plan to reorient your activities.
The Software Lifecycle (SDLC) is a period of time that begins at the moment when you decide to create any software, and ends when the development, support, and implementation of an application or service completely cease.
People have been creating software, including for various organizations, for decades. It is quite natural that during this time, different SDLC models and project management methods have been formed.
Chaotic development, when a team engages in spontaneous ideas, can sometimes bring some results. But only in small startups and as long as the main participants are enthusiastic. This resource is quickly consumed. In parallel, negative effects are snowballing. The number of bugs is multiplying, interesting functionality remains in its infancy, and the overall vision of the final product is lost. As a result, users become disillusioned and leave for competitors.
It is necessary to streamline the organization of the development of code and other elements of computer software as soon as possible. Let's briefly focus on the main approaches.
- Cascade model (waterfall model). The whole process is divided into several rigid stages. The transition to the next phase occurs only when all the work in the previous stage is completed.In practice, in its pure form, the method is suitable only for relatively small and simple projects. Customer requests change periodically, as does the entire market situation. Therefore, it is extremely difficult to create software quickly and for an acceptable budget that will cover some part of the needs once and for all (for example, working with PDF files) and will not require significant upgrades.
- V-shaped model (V-Model, VEE model). The development and testing stages are carried out in parallel. At the same time, the data received on one of the two branches affects the other. For example, the proposed basic model is analyzed and checked for compliance with industry standards. According to the results, it is being refined and complicated. The same thing happens with the architecture, prototype, and additional components of the final product.The approach requires a lot of resources, but provides reliable quality control. The method is used in industries where even minor mistakes lead to fatal consequences (space, aviation, nuclear energy, etc.).
- An iterative model. The work is carried out in parallel, the results obtained, including intermediate ones, are continuously analyzed, and current and future tasks are adjusted based on this information. This approach is now prevailing. Based on it, many other methodologies have emerged — Agile, SCRUM, Kanban, and others.The model allows you to quickly adapt to changing conditions. However, there may be problems with the correct calculation of the budget and the timing of the project. Also, with subsequent changes, sometimes it is necessary to seriously redo the original architecture.
- The spiral model. It combines successful elements of iterative and cascading approaches. Software development and implementation is conducted in cycles. At the beginning of each one, the available resources, risks, and potential opportunities are assessed. Based on this data, a list of jobs is compiled that can actually be completed by the scheduled date.The main disadvantage of the model is that it is not always possible to correctly determine the moment of transition to the next cycle. Also, sometimes the team gets too carried away and performs excessive product optimization.
Regardless of the chosen SDLC methodology, you first need to decide what to create and for whom.
There are at least several companies or single developers that offer software with similar functionality. For example, operations with PDF files can be performed in our PDF Commander, Adobe Acrobat, Foxit solutions, Microsoft Office suite, or its LibreOffice counterpart.
Make a list of software whose toolkit is similar to yours and their development companies. Thoroughly study all the features of this software. Analyze how it develops. Try to predict what changes will occur in the future, and thus perform a risk analysis for your business.
There are organizations that conduct large-scale market research to order. If you have a sufficient budget, you can apply for their services. However, you should not rely entirely on these companies. As a developer, you need to personally get acquainted with the competitors' offers. This is the only way you will understand what to create and how.
Identify the categories of customers who might benefit from your software. General, abstract formulations ("everyone who...", "all users who...") are erroneous and useless to you.
A better example: organizations with a staff of up to 50 people in the field of non-food trade use applications A, B and C.
After studying the market and potential customers, you will identify the needs of users who are not satisfied at all or are not fully satisfied. You will also identify the mistakes and problems of your competitors.
Thanks to this, you are unlikely to create an absolutely unique product. However, you can offer a product that not only solves the main (for this segment) set of tasks, but also eliminates painful problems.
I mentioned above that the process of technical software development should not be chaotic. In addition to the issues related to the organization of the team itself, this requirement also applies to all daily tasks.
When the user launches the software, he is going to solve some problem. As a rule, it is not one and consists of many additional actions.
It is necessary to anticipate as many of these possible tasks as possible and analyze the client's requirements. Then — to present all this in the form of a clear sequence of actions. Moreover, the wording should be specific, tied to real life.
A bad example: a user needs to edit a document, to do this, he opens the file and makes edits to it.
More successful: the client received the draft agreement in PDF from the counterparty. This involves the following actions::
- The document file opens in the program. It is better to combine an editor and a viewer so that the material does not have to be re-imported several times in different software. This means that the application must be lightweight enough so that the download does not take too long.
- The document is being viewed. You need options for scrolling and zooming. It is advisable to add a feature for comments and notes — if thoughts and comments appear while reading, you can add them immediately.
- Edits are being made to the document. Editing functions are required — deleting fragments, inserting new text. If the content is not recognized, an OCR (optical character recognition) tool is needed.
- The final version is saved. It is necessary to export correctly to PDF in compliance with all the requirements of the standard. The client may need to save the document in a different format. Most likely, these are DOCX, RTF, JPEG and PNG.
- The Client agrees with the counterparty's offer and is ready to sign the contract. I need a printer print function. Business practice may allow for an option where a facsimile and a print image are added to an electronic document. Electronic signatures are also often used.
Using such scenarios, it is easier to understand the real needs of customers and, based on this, offer convenient and functional solutions.
The terms of reference are usually project documentation. It varies in the degree of detail. If the development is carried out under individual contracts, the technical task is a specification of the client's requirements with an indication of the deadlines for implementation.
The first and relatively small document sets out the overall vision of the application or web service. They provide the platform, a list of main functions, the USP, a list of competing solutions, a risk assessment, and a user profile. This document is needed to tell the team what needs to be worked on (what is just talked about during meetings tends to be forgotten immediately). It can also be used to prepare a presentation for investors.
The following document details the functionality. If the software is relatively simple, you can keep and gradually add to one file. In other cases, it is advisable to keep a separate document for each function (group of similar functions). The architecture and the principle of operation of each tool are described in detail here. For better understanding, diagrams, tables, infographics, and mockups of user interfaces are added. By opening this documentation, each team member should quickly understand how the product works and what exactly needs to be done for the task.
The documentation should be clear and convenient for the team. You should not constantly experiment and abandon already accepted formats. In addition, the documentation is not static. It is absolutely normal practice to ask for clarifications and additions, to make constructive suggestions and comments.
Detailed documentation is compiled based on the current iteration of SDLC. For example, if you're implementing text formatting options in this sprint or milestone, that's exactly what you need to describe. Further, it is a good practice to attach links to the relevant sections of the documentation to specific tasks.
It is also advisable to draw up relatively long-term development plans (road maps, or roadmaps). They reflect future functionality with reference to specific dates. For example, March — adding tables, April — advanced formatting, scanner support, May — OCR, etc.
Roadmaps help you allocate resources, coordinate team activities, think better about architecture, and start product implementation in a timely manner. However, they do not always remain unchanged. Sometimes there are critical bugs that take a long time to fix. An important customer may ask to add a specific feature.
A prototype is an early version of a product. It demonstrates the operation of the main options planned for a specific iteration. Stability and visual appeal don't matter. At this stage, it is necessary to demonstrate what the specific software does and how convenient it is to use it.
Mockups are preliminary layouts or interface concepts. They demonstrate how the application will look like. Mockups are needed for product presentation, testing of some hypotheses and as illustrations in documentation.
The interface is created taking into account the functionality and other technical features. This takes into account the habits and preferences of a specific category of users.
Interface layouts show the appearance of the main window (home page), each menu, tab, tooltips, etc. They are developed taking into account user scenarios, documentation, design principles and ergonomics.
With further detailing, it is advisable to introduce elements of corporate identity — a characteristic palette, shapes, logos, fonts, and more. The visual image makes the brand recognizable and helps in promotion.
Ideally, the use of the product should bring aesthetic pleasure. At the same time, it is important to maintain a balance. You should not attach long animations and intrusive effects — they will start to annoy you very soon.
Developing recognizable, attractive, and user—friendly design concepts is an extremely difficult task. Even international corporations are not shy about assigning it to third-party specialists.
The created prototypes must be tested in real-world scenarios. At the initial stages of development, testing is conducted by team members and their loved ones (family, friends). In the future, it is advisable to involve more independent people. Friends and family members do not want to offend and upset their loved ones, so they may not report any shortcomings.
There are many testing techniques. They may include video shooting from different angles and screen capture, questionnaires, free-form reviews, and lengthy interviews. People who best match the profile of future users are invited to participate. A student, a housewife, and an office employee have different ideas about what a text editor should be like. In this case, it is better to invite employees of large, small and medium-sized companies who regularly work with large volumes of documents for testing.
Testing can be outsourced. You will have to resort to the services of third-party companies if you are located in a small provincial town and there are not enough suitable people nearby. Or are you going to enter foreign markets
During the development process, documentation and all ideas are overgrown with code and gradually transformed into one or another version of the product.
The composition of the development team depends on the functionality and architecture of the system. Taking into account modern approaches to software engineering, most activities are carried out in three directions:
- The backend. The server side (with a client-server architecture) and the internal logic of the software. Backend developers are engaged in programming the data structure, its storage and processing according to certain algorithms.
- The frontend. The client part (with a client-server architecture) and the program interface. Frontend developers make sure that all buttons-lists-menus function correctly, correctly send the source data to the internal logic and return the final result to the user.
- Integration. Application interaction with other software. These can be plug-ins, specific programming interfaces (APIs), third-party libraries, imported content, etc.
They are identical to the approaches to SDLC organization. It is advisable to choose a methodology at the earliest stages of development or even when forming a team and not change it unless absolutely necessary.
Switching to other approaches for quite a long time paralyzes all activities. Some of the colleagues will not want to adapt and will leave the company. There is a possibility that you may even have to redesign the application architecture. That is, in fact, to recreate everything that was done earlier.
Unit testing (block or unit testing) is a health check of individual isolated parts of the code. In the process, developers make sure that the various modules perform all the necessary actions, are able to interact correctly with other parts of the software and withstand certain loads.
There are ready-made unit testing libraries for software development tools. For example, NUnit for C# or JUnit for Java.
Testing and debugging of the program is not limited to early prototypes. They are regularly conducted at every stage of the life cycle.
I already mentioned it above. This is the first phase in the hierarchy of tests. Almost always, modern software consists of many relatively small modules. It is necessary to check the operability of each of them in a timely manner. This does not fully guarantee that the entire program will function as intended. However, you can get rid of some bugs in advance and reuse some of the code (of course, if it successfully passes the unit tests).
Unit testing usually starts after writing the code. Upon successful verification, it is uploaded to the version control system.
The developers check whether different modules are able to interact with each other in principle and how correctly this process occurs. Continuous integration (CIS) systems are used for this purpose. They monitor changes in version control systems. Then they run checks on individual components. If this phase is completed successfully, the compilation is performed and the interaction of the modules with each other is tested. A report is generated based on the results.
This stage should not be confused with system testing, where the entire product is tested.
They study efficiency and convenience here. QA engineers or testers are looking for bugs. They make sure that every interface element is in its place (even an experienced team sometimes forgets to add an important button or inserts a tab in the wrong window) and triggers the desired action. At the same time, they are guided by the documentation.
The convenience and overall feel (or UX) are evaluated by a focus group of users. This testing can be open (everyone can join) or closed (individually selected people and organizations participate).
QA and UX testing can be assigned to contractors. This is especially justified when large-scale checks are required in a variety of scenarios.
Upon successful completion of testing, the application is ready to enter the market.
In most cases, mobile applications are distributed through the built-in stores of the respective platforms. For iOS and iPad OS, this is the only possible option (hacking the firmware and various rather complicated schemes are not considered). Android apps can be installed from APK files. However, this method is only suitable for specific cases. For example, the program is distributed only under individual contracts with customers.
To place software in stores, you need to register a developer account (App Store, Google Play). In the process, you will have to fill out a questionnaire and pay a small fee.
Computer software is distributed through it. You can launch a separate resource or create an additional section on the developer's website. You will need pages with detailed information about the software and its cost, documentation, and the functionality of a shopping cart with the ability to process payments and automatically send out license keys or distributions.
Promotion is usually started before the release. Marketing strategies depend on the market segment you are positioning your product for. Solutions for large corporate customers are presented at offline events. A certain number of clients can be obtained at exhibitions, after publications in industry publications and distribution of commercial offers.
Software for smaller customers can be promoted through specialized bloggers. Content marketing shows good results. It consists in regularly posting useful materials, the subject of which coincides with the purpose of your application. For example, if the program allows you to create and process PDF documents, you can upload articles and videos with tips on digitizing paper materials, converting to different formats, and adding electronic signatures. Thus, user training is conducted simultaneously with the promotion.
The effect of content marketing is not immediately apparent. Usually — not earlier than in six months or a year. In parallel, you need to use SEO and SMM techniques when promoting on websites and on social networks, respectively.
For monitoring, they use their own analytics tools, the functionality provided by mobile stores, and other methods. They study the number of downloads, installations and launches, purchases of licenses and subscriptions, the duration of sessions, the number of restarts a few days after installation, the status of servers and the content of logs. The obvious warning signal is angry feedback and calls to tech support.
Software creation does not stop after the release. According to many modern methodologies, development is basically conducted over an infinite number of cycles until there is a demand for the product or you offer a replacement.
Reviews are sent through the functionality of the stores and feedback forms. Customers can also express their opinions in comments on official social media pages, via email, and through technical support channels.
The stores evaluate the average rating of the app and the developer's interaction with the reviews. This data is used for automatic recommendation and promotion systems, including feature creation. Responses (they should always be polite) to comments have a positive effect.
You can encourage users to share their opinions. During the operation of the software, display windows with relevant suggestions, and send newsletters based on their contact information. However, don't be too intrusive.
Fixes for critical bugs and vulnerabilities are provided as soon as possible. The schedule of planned updates is determined by agreements with key clients and the chosen development methodology. Usually — every 3-4 weeks or less.
Too frequent scheduled updates for corporate software are undesirable. As a rule, updates in organizations are carried out centrally and by system administrators. Internal testing and security checks can be performed beforehand. Since this is a time-consuming and time-consuming process, treat other people's time with respect.
Updates must be documented. Relevant news is posted on the pages in the stores, on the website and in social networks. Detailed patchnotes (changelogs) are also posted on official online resources. At the same time, the reference materials are updated. It is advisable to duplicate the information. Due to the restrictions on the number of characters in the stores, it is not always possible to describe all the features of the release, and not all customers are subscribed to the social network.
VIP clients may need initial technical documentation and consultations directly with the project manager and developers. Interaction schemes must be agreed upon in advance — when concluding contracts.
The information obtained during the user support process may directly indicate certain shortcomings. However, the data needs to be evaluated comprehensively and rechecked with additional tests.
Requirements can also be collected through feedback channels. They often receive requests for new features. It is not always possible or advisable to release appropriate updates. Sometimes it requires a complete redesign of the architecture and expensive research.
Internal analytics tools provide invaluable information for product development. They track the number of activations of each function, the duration of all sessions, window views, hardware characteristics, and more. If some of the options are almost not used, you can publish a number of reference publications (to stimulate interest) or temporarily not waste resources on their further development. However, such analytics tools are not suitable for offline products, software that runs in a closed infrastructure, or if maximum confidentiality is essential for customers.
I shared basic information about how software developers create enterprise software. It all starts with choosing a methodology. In recent decades, the spiral and iterative approaches have prevailed. Next, you need to carefully study the market and create a portrait of a potential customer. Based on these data, formulate the USP features that will distinguish your offer from the mass of competitors.
The development itself is accompanied by testing, including involving real users. A product release is not the end of a project. Marketing activities, regular updates, monitoring of metrics and feedback are necessary.
Приветствую! Я Тимур Драгунов. Уже более 10 лет работаю в сфере IT. Карьеру начинал как разработчик интернет-проектов. Позже присоединился к команде российского редактора PDF Commander. В последние годы мы с коллегами сфокусировались на корпоративном сегменте. Эта часть рынка традиционно считается более доходной, чем выполнение проектов для обычных пользователей. К тому же у значительной части потенциальных заказчиков появился спрос на альтернативы решениям от крупных международных компаний.
Впрочем, на смену направления работы повлияли не только эти два фактора. У корпоративных клиентов требования жестче и есть запрос на решение специфических задач. Для нас это стало серьезным вызовом и помогло найти новые пути профессионального развития. Я расскажу подробнее про этапы разработки программного обеспечения для организаций. Эта информация пригодится, если вы с командой планируете переориентировать свою деятельность.
0 этап: что нужно знать про жизненный цикл корпоративного ПО
Жизненный цикл ПО (SDLC — Software Development Lifecycle) — это период времени, который начинается в тот момент, когда вы решаете создать какой-либо софт, а заканчивается, когда разработка, поддержка и реализация приложения или сервиса полностью прекращаются.
Люди занимаются созданием ПО, в том числе для всевозможных организаций, десятилетиями. Вполне закономерно, что за это время сформировались разные модели SDLC и методы управления проектами.
Хаотичная разработка, когда команда занимается спонтанно возникающими идеями, иногда может приносить некоторые результаты. Но только в небольших стартапах и до тех пор, пока основные участники полны энтузиазма. Этот ресурс быстро расходуется. Параллельно как снежный ком растут негативные эффекты. Множится число багов, интересный функционал остается в зачаточном состоянии, теряется общее видение конечного продукта. В итоге пользователи разочаровываются и уходят к конкурентам.
Необходимо как можно скорее упорядочить организацию разработки кода и других элементов компьютерного программного обеспечения. Кратко остановимся на основных подходах.
- Каскадная модель (waterfall, модель водопада). Весь процесс делится на несколько жестких стадий. Переход к следующей фазе происходит только тогда, когда будут полностью выполнены все работы на предыдущем этапе.
На практике в чистом виде метод подходит только для относительно небольших и простых проектов. Запросы клиентов периодически меняются, как и вся ситуация на рынке. Поэтому крайне сложно быстро и за приемлемый бюджет создать софт, который раз и навсегда закроет какую-то часть потребностей (например, работу с PDF-файлами) и не понадобятся существенные модернизации. - V-образная модель (V-Model, VEE модель). Параллельно проводятся этапы разработки и тестирования. При этом данные, полученные на одной из двух ветвей, влияют на другую. Например, предложенная базовая модель анализируется и проверяется на соответствие отраслевым стандартам. По результатам — дорабатывается и усложняется. То же самое происходит с архитектурой, прототипом, дополнительными компонентами финального продукта.
Подход требует много ресурсов, но обеспечивает надежный контроль качества. К методу прибегают в отраслях, где даже незначительные ошибки приводят к фатальным последствиям (космос, авиация, атомная энергетика и т.п.). - Итеративная модель. Работы ведутся параллельно, полученные результаты, включая промежуточные, непрерывно анализируются, и на основе этой информации корректируются текущие и будущие задачи. Этот подход сейчас преобладает. На его основе возникло множество других методологий — Agile, SCRUM, Канбан и другие.
Модель позволяет быстро адаптироваться к меняющимся условиям. Однако возможны проблемы с правильным подсчетом бюджета и сроков реализации проекта. Также при последующих изменениях иногда приходится серьезно переделывать изначальную архитектуру. - Спиральная модель. Сочетает в себе удачные элементы итеративного и каскадного подходов. Разработка и внедрение программного обеспечения ведется циклами. В начале каждого оцениваются доступные ресурсы, риски и потенциальные возможности. На основе этих данных составляется список работ, которые реально выполнить к назначенной дате.
Основной недостаток модели заключаются в том, что не всегда удается правильно определить момент перехода на следующий цикл. Также иногда команда слишком увлекается и проводит избыточную оптимизацию продукта.
1 этап: работа над концепцией и идеей
Независимо от выбранной методологии SDLC, сперва нужно определиться с тем что и для кого создавать.
Исследование рынка и конкурентов
Существует как минимум несколько компаний или разработчиков-одиночек, которые предлагают софт с похожей функциональностью. Например, операции с PDF-файлами можно выполнять в нашем PDF Commander, Adobe Acrobat, решениях от Foxit, пакете Microsoft Office или в его аналоге LibreOffice.
Составьте список ПО, инструментарий которого похож на ваш, и их компаний-разработчиков. Досконально изучите все особенности этого софта. Проанализируйте, как он развивается. Постарайтесь спрогнозировать, какие изменения произойдут в будущем, и тем самым выполните анализ рисков для своего бизнеса.
Существуют организации, которые проводят масштабные исследования рынка на заказ. При достаточном бюджете можно обратиться за их услугами. Однако полностью полагаться на эти компании не стоит. Вам как разработчику нужно лично знакомиться с предложениями конкурентов. Только так вы будете понимать, что и как создавать.
Составление портрета пользователя
Определите категории клиентов, которым может пригодиться ваше ПО. Общие, абстрактные формулировки («все, кто…», «все пользователи, которым…») ошибочны и бесполезны для вас.
Более удачный пример: организации со штатной численностью до 50 человек, в сфере торговли непродовольственными товарами, используют приложения А, В и С.
Определение уникального торгового предложения (USP)
Изучив рынок и потенциальных клиентов, вы установите потребности пользователей, которые не удовлетворены совсем или удовлетворены не полностью. Также вы определите ошибки и проблемы конкурентов.
Благодаря этому вы вряд ли создадите абсолютно уникальный товар. Однако сможете предложить продукт, который не только решает основной (для этого сегмента) набор задач, но и устраняет наболевшие проблемы.
2 этап: планирование и проектирование
Выше я уже упоминал, что процесс технической разработки программного обеспечения не должен быть хаотичным. Помимо моментов, связанных с организацией самой команды, это требование также касается всех повседневных задач.
Составление пользовательских сценариев
Когда пользователь запускает ПО, он собирается решить некоторую задачу. Как правило, она не одна и состоит из множества дополнительных действий.
Необходимо предугадать как можно больше таких возможных задач и провести анализ требований клиента. Затем — представить все это в виде четкой последовательности действий. Причем формулировки должны быть конкретными, привязанными к реальной жизни.
Плохой пример: пользователю необходимо отредактировать документ, для этого он открывает файл и вносит в него правки.
Более удачный: клиент получил проект договора в PDF от контрагента. Это предполагает следующие действия:
- Файл документа открывается в программе. Лучше совместить редактор и просмотрщик, чтобы материал не пришлось по несколько раз переимпортировать в разном софте. Значит, приложение должно быть достаточно легковесным, чтобы загрузка не происходила слишком долго.
- Документ просматривается. Нужны опции для скроллинга и масштабирования. Желательно добавить функцию комментариев и пометок — если при чтении появятся мысли и замечания, их можно сразу же добавить.
- В документ вносятся правки. Требуются функции редактирования — удаление фрагментов, вставка нового текста. Если содержание не распознано, нужен инструмент для OCR (оптического распознавания символов).
- Финальный вариант сохраняется. Необходим корректный экспорт в PDF с соблюдением всех требований стандарта. Возможно, клиенту нужно сохранить документ в другой формат. Вероятнее всего, это DOCX, RTF, JPEG и PNG.
- Клиент согласен с предложением контрагента и готов подписать договор. Нужна функция печати на принтере. Деловая практика может допускать такой вариант, когда в электронный документ добавляется факсимиле и изображение печати. Также часто используются электронные подписи.
При помощи подобных сценариев проще понять реальные потребности заказчиков и на основе этого предлагать удобные и функциональные решения.
Разработка ТЗ: структура, требования, ограничения
Обычно техническое задание — это документация по проекту. Она различается по степени детализации. Если разработка выполняется по индивидуальным контрактам, техзадание — это спецификация требований клиента с указанием сроков реализации.
В первом и относительно небольшом по объему документе излагают общее видение приложения или веб-сервиса. Приводят платформу, список основных функций, USP, перечень конкурирующих решений, оценку рисков, описывают портрет пользователя. Этот документ нужен, чтобы сообщить команде, над чем предстоит работать (то, что просто проговаривается во время собраний, имеет свойство тут же забываться). На его же основе можно подготовить презентацию для инвесторов.
Следующий документ детализирует функционал. Если ПО относительно простое, можно вести и постепенно дополнять один файл. В остальных случаях желательно под каждую функцию (группу схожих функций) вести отдельный документ. Здесь подробно описывают архитектуру, принцип работы каждого инструмента. Для лучшего понимания добавляют схемы, таблицы, инфографику, мокапы пользовательских интерфейсов. Открыв эту документацию, каждый член команды должен быстро понять, как работает продукт и что именно нужно делать по задаче.
Документация должна быть понятной и удобной для команды. Не стоит постоянно экспериментировать и отказываться от уже принятых форматов. Кроме того, документация не статична. Абсолютно нормальная практика — просить уточнений и дополнений, высказывать конструктивные предложения и замечания.
Детальную документацию составляют с учетом текущей итерации SDLC. Например, если в этом спринте или майлстоуне вы внедряете опции форматирования текста, именно их и нужно описывать. Далее хорошей практикой будет прикреплять к конкретным задачам ссылки на соответствующие разделы документации.
Также желательно составлять относительно долгосрочные планы развития (дорожные карты, или roadmap). В них отражают будущий функционал с привязкой к определенным датам. Например, март — добавление таблиц, апрель — расширенное форматирование, поддержка сканеров, май — OCR, и т.д.
Roadmap-ы помогают распределять ресурсы, координировать деятельность команды, лучше продумывать архитектуру, своевременно начинать внедрение продукта. Однако они не всегда остаются в неизменном виде. Иногда появляются критические баги, на устранение которых уходит много времени. Важный клиент может попросить добавить определенную функцию.
Создание прототипов или мокапов
Прототип — это ранняя версия продукта. В нем демонстрируется работа основных опций, запланированных на определенную итерацию. Стабильность и визуальная привлекательность не имеют значения. На этом этапе необходимо продемонстрировать, что делает конкретное ПО и насколько удобно им пользоваться.
Мокапы — предварительные макеты или концепты интерфейса. Они демонстрируют, как будет выглядеть приложение. Мокапы нужны для презентации продукта, проверки некоторых гипотез и в качестве иллюстраций в документации.
3 этап: разработка интерфейса и пользовательского опыта (UI/UX)
Интерфейс создается с учетом функционала и других технических особенностей. При этом учитываются привычки и предпочтения конкретной категории пользователей.
Создание визуальных концепций
Макеты интерфейса демонстрируют внешний вид основного окна (главной страницы), каждого меню, вкладки, всплывающих подсказок и т.д. Их разрабатывают с учетом пользовательских сценариев, документации, принципов дизайна и эргономики.
При дальнейшей детализации желательно привнести элементы фирменного стиля — характерную палитру, формы, логотипы, шрифты и прочее. Визуальный образ делает бренд узнаваемым и помогает в продвижении.
В идеале пользование продуктом должно приносить эстетическое удовольствие. При этом важно соблюдать баланс. Не стоит прикреплять долгие анимации и навязчивые эффекты — совсем скоро они начнут раздражать.
Разработка узнаваемых, привлекательных и удобных концепций дизайна — крайне сложная задача. Даже международные корпорации не стесняются поручать ее сторонним специалистам.
Тестирование прототипов с участием пользователей
Созданные прототипы необходимо проверять в реальных сценариях. На начальных этапах разработки тестирование проводится членами команды и их близкими (семьей, друзьями). В дальнейшем желательно привлекать больше независимых людей. Друзья и члены семей не хотят обижать и расстраивать своих близких, поэтому могут не сообщать о недостатках.
Существует множество методик тестирования. Они могут предусматривать видеосъемку с разных ракурсов и захват экрана, анкетирование, отзывы в свободной форме, продолжительные интервью. К участию привлекаются люди, максимально соответствующие портрету будущих пользователей. У студента, домохозяйки и офисного служащего разные представления о том, каким должен быть редактор текстов. В этом случае лучше пригласить на тестирование сотрудников крупных, мелких и средних компаний, которые регулярно работают с большими объемами документов.
Тестирование можно отдать на аутсорс. К услугам сторонних компаний придется прибегнуть, если вы находитесь в небольшом провинциальном городе и поблизости нет достаточно числа подходящих людей. Или собираетесь выходить на иностранные рынки
4 этап: разработка и код
В процессе разработки документация и все идеи обрастают кодом и постепенно превращаются в ту или иную версию продукта.
Работа программистов: фронтенд, бэкенд, интеграция
Состав команды разработчиков зависит от функционала и архитектуры системы. С учетом современных подходов к программной инженерии чаще всего деятельность ведется по трем направлениям:
- Бэкенд. Серверная часть (при клиент-серверной архитектуре) и внутренняя логика ПО. Бэкенд-разработчики занимаются программированием структуры данных, их хранения и обработки по определенным алгоритмам.
- Фронтенд. Клиентская часть (при клиент-серверной архитектуре) и интерфейс программы. Фронтенд-разработчики делают так, чтобы все кнопки-списки-меню правильно функционировали, корректно отправляли исходные данные во внутреннюю логику и возвращали пользователю конечный результат.
- Интеграция. Взаимодействие приложения с другим ПО. Это могут быть плагины, определенные программные интерфейсы (API), сторонние библиотеки, импортируемый контент и т.п.
Методологии
Они идентичны подходам к организации SDLC. Методологию желательно выбирать на самых ранних стадиях разработки или еще при формировании команды и не менять без крайней необходимости.
Переход на другие подходы на достаточно долгое время парализует всю деятельность. Кто-то из коллег не захочет адаптироваться и покинет компанию. Существует вероятность, что вам даже придется заново проектировать архитектуру приложения. То есть фактически заново пересоздавать все проделанное ранее.
Проведение первых модульных тестов
Модульное тестирование (блочное или юнит-тестирование) — проверка работоспособности отдельных изолированных частей кода. В процессе разработчики удостоверяются, что различные модули выполняют все нужные действия, способны корректно взаимодействовать с другими частями ПО и выдерживают определенные нагрузки.
Для инструментов разработки программного обеспечения есть готовые библиотеки юнит-тестирования. Например, NUnit для C# или JUnit для Java.
5 этап: проверка работоспособности, безопасности, производительности
Тестирование и отладка программы не ограничиваются ранними прототипами. Оно регулярно проводятся на каждом этапе жизненного цикла.
Юнит-тестирование
Я уже упоминал его выше. Это первая фаза в иерархии тестов. Почти всегда современное ПО состоит из множества относительно мелких модулей. Необходимо своевременно проверять работоспособность каждого из них. Это не дает полной гарантии, что вся программа будет функционировать, как задумано. Однако вы сможете заранее избавиться от некоторых багов и повторно использовать часть кода (конечно, если она успешно пройдет юнит-тесты).
Обычно юнит-тестирование запускается после написания кода. При успешной проверке он загружается в систему контроля версий.
Интеграционное тестирование
Разработчики проверяют, способны ли разные модули в принципе взаимодействовать друг с другом и насколько корректно происходит этот процесс. Для этого задействуются системы непрерывной интеграции (CIS). Они отслеживают изменения в системах контроля версий. Затем запускают проверки отдельных компонентов. Если эта фаза пройдена успешно, выполняется компиляция и тестируется взаимодействие модулей между собой. По результатам генерируется отчет.
Этот этап не стоит путать с системным тестированием, на котором проверяется весь продукт.
Тестирование интерфейса и UX
Здесь изучают работоспособность и удобство. Поиском багов занимаются QA-инженеры или тестировщики. Они проверяют, чтобы каждый элемент интерфейса был на своем месте (даже опытная команда иногда забывает добавить важную кнопку или вставляет вкладку не в то окно) и запускал нужное действие. При этом руководствуются документацией.
Удобство и общие ощущения (или UX) оценивает фокус-группа пользователей. Это тестирование может быть открытым (присоединяются все желающие) или закрытым (участвуют индивидуально отобранные люди и организации).
QA и UX-тестирование можно поручать подрядчикам. Это особенно оправдано, когда требуются масштабные проверки во множестве сценариев.
Этап 6: финальный релиз продукта
При успешном завершении тестирования приложение готово к выходу на рынок.
Загрузка приложения в магазины (App Store, Google Play)
Мобильные приложения в большинстве случаев распространяется через встроенные магазины соответствующих платформ. Для iOS и iPad OS это единственный возможный вариант (взлом прошивки и разные достаточно сложные схемы не рассматриваем). В Android приложения можно устанавливать из APK-файлов. Однако этот способ подходит только для специфических случаев. Например, программа распространяется только по индивидуальным контрактам с заказчиками.
Чтобы размещать софт в сторах, нужно зарегистрировать аккаунт разработчика (App Store, Google Play). В процессе придется заполнить анкету и внести небольшую плату.
Создание сайта десктопного продукта
Через него распространяется софт для компьютеров. Можно запустить отдельный ресурс или сделать дополнительный раздел на сайте разработчика. Потребуются страницы с подробной информацией о ПО и его стоимости, документацией и функционал корзины с возможностью обработки платежей и автоматической рассылкой лицензионных ключей или дистрибутивов.
Презентация и маркетинговые кампании
К продвижению обычно приступают до релиза. Маркетинговые стратегии зависят от того сегмента рынка, на который вы позиционируете продукт. Решения для крупных корпоративных заказчиков презентуют на офлайн-мероприятиях. Некоторое число клиентов можно получить на выставках, после публикаций в отраслевых изданиях и рассылки коммерческих предложений.
ПО для более мелких заказчиков можно продвигать через профильных блогеров. Неплохие результаты показывает контент-маркетинг. Он заключается в регулярном размещении полезных материалов, тематика которых совпадает с назначением вашего приложения. Например, если программа позволяет создавать и обрабатывать PDF-документы, можно выкладывать статьи и ролики с советами по оцифровке бумажных материалов, конвертации в разные форматы, добавлению электронных подписей. Таким образом, одновременно с продвижением ведется обучение пользователей.
Эффект от контент-маркетинга проявляется не сразу. Обычно — не ранее чем через полгода-год. Параллельно нужно задействовать приемы SEO и SMM при продвижении на сайтах и в соцсетях соответственно.
Мониторинг первых дней работы
Для мониторинга используют собственные инструменты аналитики, функционал, который предоставляют мобильные сторы, и другие методы. Изучают количество скачиваний, установок и запусков, покупок лицензий и оформленных подписок, продолжительность сессий, число повторных запусков спустя несколько дней после инсталляции, состояние серверов и содержание логов. Очевидный тревожный сигнал — гневные отзывы и обращения в техподдержку.
7 этап: сбор обратной связи, исправление багов, добавление нового функционала
После релиза создание ПО не останавливается. По многим современным методологиям, разработка в принципе ведется по бесконечному количеству циклов, пока на продукт есть спрос или вы не предложите замену.
Мониторинг отзывов
Отзывы отправляются через функционал сторов и формы обратной связи. Также клиенты могут высказывать свое мнение в комментариях на официальных страницах в соцсетях, по электронной почте и через каналы техподдержки.
Сторы оценивают среднюю оценку приложения и взаимодействие разработчика с отзывами. Эти данные используются для систем автоматических рекомендаций и продвижения, в том числе фичеринга. Позитивный эффект дают ответы (они всегда должны быть вежливыми) на комментарии.
Можно стимулировать пользователей делиться мнением — в процессе эксплуатации ПО выводить окна с соответствующим предложениям, делать рассылки по оставленным контактным данным. Однако не будьте слишком навязчивыми.
Выпуск обновлений
Исправления критических ошибок и уязвимостей предоставляют в максимально сжатые сроки. График плановых обновлений определяют соглашения с ключевыми клиентами и выбранная методология разработки. Обычно — каждые 3-4 недели или реже.
Слишком частые плановые апдейты для корпоративного ПО нежелательны. Как правило, обновления в организациях проводятся централизованно и системными администраторами. Предварительно могут выполняться внутренние тестирования и проверки безопасности. Поскольку это трудоемкий и длительный процесс, относитесь с уважением к чужому времени.
Обновления обязательно документируют. На страницах в сторах, на сайте и в соцсетях размещают соответствующие новости. Также на официальных онлайн-ресурсах выкладывают подробные патчноуты (списки изменений). Одновременно с этим актуализируют справочные материалы. Желательно дублировать информацию. Из-за ограничений на количество символов в сторах не всегда удается расписать все особенности релиза, а на соцсети подписаны не все заказчики.
VIP-клиентам может требоваться исходная техническая документация и консультации непосредственно с менеджером проекта и разработчиками. Схемы взаимодействия необходимо согласовывать заранее — при заключении договоров.
Оценка пользовательских данных для улучшений
Информация, полученная в процессе поддержки пользователей, может прямо указывать на определенные недостатки. Однако данные нужно оценивать комплексно и перепроверять дополнительными тестами.
Сбор требований может проводиться и через каналы обратной связи. На них нередко приходят пожелания о новых функциях. Выпускать соответствующие обновления не всегда возможно или целесообразно. Иногда для этого приходится полностью переделывать архитектуру и проводить дорогостоящие исследования.
Бесценную информацию для развития продукта дают инструменты внутренней аналитики. Они отслеживают количество активаций каждой функции, длительность всех сессий, просмотра окон, характеристики аппаратного обеспечения и прочее. Если какие-то из опций почти не используются, можно выпустить ряд справочных публикаций (чтобы стимулировать интерес) или временно не тратить ресурсы на их дальнейшее развитие. Однако такие инструменты аналитики не подходят для офлайновых продуктов, софта, который запускается в закрытой инфраструктуре, или если для клиентов принципиальна максимальная конфиденциальность
Резюмирую
Я поделился основной информацией о том, как разработчики программного обеспечения создают корпоративный софт. Все начинается с выбора методологии. В последние десятилетия преобладают спиральный и итеративный подход. Далее нужно тщательно изучить рынок и составить портрет потенциального заказчика. На основе этих данных сформулировать USP — особенности, которые выделят ваше предложение из массы конкурентов.
Непосредственно разработка сопровождается тестированием, в том числе с привлечением реальных пользователей. Выпуск продукта не является завершением проекта. Необходимы маркетинговые активности, регулярные апдейты, мониторинг метрик и обратной связи.
