PACS – foundation knowledge and application

What does PACS stand for?

It’s Picture Archiving and Communication System – PACS

Digital Imaging Processing

As its name – the purpose is to store images (from modalities) and communicate with other digital systems (Hospital Information System – HIS, Radiological Information System – RIS, etc.)

Why PACS?

  • Reduce the use of x-ray films
  • Centralize all radiological images from different modalities (CT, X-Ray, MRI, etc.)
  • Remote access and permission restricted access of digital medical images
  • Advanced image processing technologies (3D, auto-detect, advisory, etc.)
  • Automate the hospital process (together with the integrations to RIS, HIS)
too much trash from medical images
Save the world by reducing medical images!

What is DCOM?

It’s Digital Imaging and Communications in Medicine – DCOM

This is the standard for communication and managing medical images and data which is used worldwide

This standard acts as the backbone to support PACS systems up and running seamlessly while interacting with various imaging modalities.

Reference

Mess in exploring product metrics

Product Metrics what matter

Data-driven is a word that we always hear while talking about product development or business decision making.

Let’s focus on software development, what are the basic metrics we should focus on? This question may be a bit challenging to anyone working in a product team. In this post, I’ll try to answer that question by covering the foundation of Product Metrics.

Committed Monthly Recurring Revenue (CMRR)

This metric is extremely important to evaluate how the company is making money. Continuous growth is a good sign for investors to spend more money even though the company is not profitable yet.

However, continuous growing revenue is not always a good sign of making good business. This is one of the biggest illusion of product scaling. Stable revenue growth needs to have stable cohort-based dollar retention. In other words, revenue is not everything yet. We also need to keep Cost Per Acquisition (CPA) as low as possible, Life Time Value (LTV) as high as possible.

Increasing CMMR with High Churn Rate
Increasing CMMR with Low Churn Rate

From 2 images above, we can easily know that LTV of the first case is very low since about 80% of new users are constantly leaving the product. To maintain the increasing CMRR, it requires a huge incremental investment to acquire new users who could fill in the missing ones.

If both companies stopped advertising campaigns (due to the economic crisis) in 2018, CMRRs would have dropped dramatically (which showed clearly in the above diagrams). Luckily, not all the investors were looking at other metrics besides CMRR and the economy was growing well 🙂.

Cost Per Acquisition (CPA)

This represents how much it costs to acquire a new customer. The lower CPA, the better. We have lower level metrics to evaluate this like:

  • Advertising cost per thousand (CPM): the cash investment for advertising on average (via all platforms) to acquire 1000 subscribers
  • Visits to lead: number of visits required to transform a visitor to an engaged client
  • Visits to subscriptions: number of visits required to transform an engaged client to an official subscriber

Life Time Value (LTV)

The amount of money each customer could bring to the company in the whole user lifetime. Logically, a profitable business requires “CPA < LTV”.

Churn Rate

The percentage of customers who are leaving the product / cancel the subscriptions (typically in a month).

Notice that Churn Rate can still be high although revenue and number of users are increasing. It’s possible as long as the number of new users is greater than the number of left users. We can accomplish this by spending massive advertising, promotion campaigns which noted as operation cost/investment.

Churn Rate calculation

North Star Metric

This metric visualize how the product is reaching its vision and goals. Usually the actions measured for this metric is the key flow of the product. The more users go through this flow, the more successful the product is in terms of solving user problems, increasing user lives.

These are some examples:

  • Mobile Commerce Business: number of mobile orders delivered
  • Facebook in early days: number of users adding 7 friends in the first 10 days
  • Grown hack in SAAS companies: trial accounts with more than 3 users active in week 1

Net Promoter Score (NPS)

This is the core metric to measure the overall customer perception of the product which can help predict grown opportunity.

NPS calculation

Nowadays, it’s a very popular tool being applied by most of the product teams to identify users’ critical pain points in using the products as well as identify the added values which users value the most.

Conclusion

Having metrics is fancy but reading them is difficult. We all should be very careful in extracting the meanings behind any charts, diagrams because the whole meaning can be changed by having other contexts.

Hope you found some meaningful information out of this blog. Give me comments for any suggestions. Thank you!

Reference:

Agile Product Management with Scrum – Roman Pichler

This is the best book about Agile Management that I’ve ever read. Thank you so much, Roman.

If you want to get the best out of this book, of course you need to read the whole of the book. The purpose for this article is to note critical things that I found out throughout tons of valuable information and advices.

1. Product Owner role

First of all, forget all about other traditional development framework. To have an agile team, product owner is crucial and the biggest challenge.

Characteristic of a product owner:

  • visionary and doer
  • leader and team player
  • communicator and negotiator
  • empowered and committed
  • available and qualified

“Being adequately qualified usually requires an intimate understanding of the customer and the market, being passionate about the user experience, and the ability to communicate needs and describe requirements, to mange a budget, to guide a development project, and to be comfortable working with a cross-functional, self-organizing team

“Since the product owner of a component team has to help translate product backlog items into technical requirements, the best individual to serve in that role is usually an architect or a senior developer rather than a product manager

A product owner committee is a group of product owners without anyone in charge of the overall product. There is no one person guiding the group, helping to create a common goal, and facilitating decision making. A product owner committee is in danger of getting caught in endless meetings with conflicting interests and politics – something also referred to as “death by committee”. No real progress is achieved; people stop collaborating and start fighting each other.”

The chief product owner guides the other product owners. This individual ensures that needs and requirements are consistently communicated to the various teams, and that the project-wide process is optimized. This includes facilitating collaborative decision making as well as having the final say if no consensus can be reached.”

As a product owner, you guide and influence the team. You behavior matters. A lot.”

2. Product Vision

Being able to envision what a new product or the next product vision should look like and do is essential for getting there.”

The vision acts the overarching goal, galvanizing and guiding people, and is the product’s reason for being.”

A vision is truly shared when you and I have a similar picture and are committed to one another having it, not just to each of us, individually, having it” 

“The product vision should describe the broad and engaging goal: a goal that guides the development efforts but leaves enough room for creativity, a goal that engages and inspires people.”

When it comes to product vision, less is more. The vision should be brief and concise. It should contain only information critical to the success of the product.”

“As our ability to predict the future is limited, our best chance of success is to envision the minimal marketable product, a product with minimum functionality that meets the selected customer needs.”

“By reducing time to market, we are able to listen and respond to the marketplace more frequently, rather than trying to outguess it… This allows us to build the possibility of failure into our strategy, an approach Google has embraced.”

Launch the product quickly, inspect the market response, and adapt the product accordingly

Simplicity is the ultimate sophistication” Leonardo da Vinci

“Whenever you have an idea for a new feature or you discover a new requirement, ask yourself if the new functionality is critical to the success of the product. If not, discard the idea.”

“Refrain from putting too many controls and procedures around the visioning work.”

“Keep the vision humble and focused on the upcoming product vision. Think big, but start small

Customer needs and product attributes are at the heart of the vision and deserve close attentionNonfunctional attributes can be an important differentiator – they can impact the user experience as well as the extensibility and maintainability of the product, which intern influence the total cost of ownership and the product’s life expectancy.”

3. Product Backlog

Definition: it is simply a prioritized list of the things which can bring product to life. The mot important items are found at the top.

Requirements are no longer handed off to the team; the team members coauthor them.”

“A requirement is clear if all Scrum team members have a common understanding of its semantics

“A well-groomed backlog is a prerequisite for a successful sprint planning meeting.”

“Treat existing requirements as suspicious and consider them as a liability, not an asset”

“Because risk and uncertainty influence product success, uncertain and risky items should be high-priority

“Dependencies restrict the freedom to prioritize the product backlog and influence the effort estimates; the item on which others depend has to be implemented first. You should therefore try to resolve dependencies whenever possible

4. Release planning

Adding manpower to a late software project makes it later.”

“Even though release planning is a collaborative effort, the product owner is responsible for ensuring that the necessary decisions are made.

Compromising software quality means trading in short-term gains for longer-term growth. You would cheat yourself of a better, brighter future”

“More precisely, velocity is the sum of the effort for the work results accepted by the product owner in a sprint.”

“To get the most out of the plan, I like to show the functionality each release will provide in terms of themes and epics. Showing stories in the release plan tends to introduce too much detail”

“Whatever tool is used, though, the plan should create transparency and facilitate dialogue between the Scrum team and stakeholders”

Pipelining is a last resort. You should employ this technique only if all other options have failed.”

Using feature teams rather than component teams whenever possible will reduce the need for pipelining.”

“In fact, the product owner should drive the release planning activities. As the person first and foremost responsible for the success of the product, it is in the best interest of the product owner to guide the project proactively.”

5. Becoming great Product Owner

“The product owner role is multi-faceted. It’s difficult – perhaps impossible – to find new product owners who have every necessary skill. You can therefore expect to find gaps in your own knowledge and skills.”

“Listen to feedback from your fellow Scrum team members, and work on the remaining gaps in knowledge and skills”

“Without sponsorship form the right level, you are likely to lack authority and, as a consequence, will struggle to do a good job.”

“Senior manager must recognize the authority and responsibility of the product owner role and the likely impact it is going to have on the organization. Doing so is not only crucial for making agile product management work, but it is also a critical success factor for any Scrum adoption”

“Product owners must be selected with care”

 

Thank you. Hope you had a good read!

business analyst in Agile development

Business Analyst role in Agile development – BA work in Scrum team

Normally in Agile development, people don’t mention about Business Analyst role. So what will be the true story behind the scene?

Business analysts play an important role: Traditionally, they act as the link between the business units and IT, help to discover the user needs and the solution to address them, and specify requirements. But in Scrum, there is no business analyst role. (Roman Pichler)

What will BA do in a Scrum team?

Option 1: product owner

This is a natural move. The individual needs to own the product on behalf of the company instead of analyse and get features approval from specific clients. For that significant change, the individual might need to learn new skills to adapt new role.

Option 2: team member

The role of business analyst as a team member will mostly to address and help other members groom product backlog. Since this responsibility is for the whole team, business analyst inside a Scrum team usually covers additional tasks as well like writing technical documents, coordinate with testers.

The role of a Business Analyst in an Agile project is not well-defined just as there is no defined role for a Project Manager on an Agile project. On small, simple Agile projects there may not be a need for either of these two roles but that is frequently not the case on large, complex enterprise-level projects.

The role of a BA is often neglected – it is assumed that the Product Owner plays that role but it can be difficult for a Product Owner to perform that role without some assistance on very large complex projects

(chuckc3)

Option 3: proxy product owner

Dealing half-heartedly with the role of business analysts in Scrum is a common mistake: Business analysts neither play the product owner role nor are they team members. Instead, they end up as proxy product owners, a go-between the real decision maker and the development team, as shown blow.

Using a proxy product owner is best avoided—certainly as a permanent solution.

(Roman Pichler)

Why this model is not-recommended? Because it requires many communication to verify each single decision thus brings lots of miscommunication, misunderstanding as well as inconsistent product requirements. At the end, no one is really the Owner of Product.

The head of a business unit was asked to take on the product owner role for a new product. As he struggled to fill the role effectively, the business analyst stood in as a proxy. While the analyst did all the detailed grooming work, the business unit head decided about the product features and when which functionally was released. Unfortunately, this resulted in miscommunication, a long-winded decision-making process, and poor morale. (Roman Pichler)

Conclusion

There is no fixed direction, solution for a traditional business analyst to follow in Scrum world. But I think from the above suggestions, insights, we’re all more clear about the basic concepts.

Scrum is not a plug-and-play environment that will guarantee that product development will succeed. If improperly managed, the product development will not adequately scale to the customer’s requirements, which will increase costs, impact return on investment, and lead to instability. (Sriramasundararajan Rajagopalan)

Reference:

Scrum development – basic and common problems

Scrum is widely used by many companies, organizations but to really know its true principles and practical methods is very hard. People always say that they are using Scrum for development but no one can really say that how many percentages of Scrum principles they are applying in reality.

Let work through the Scrum foundation and some common problems to find out that percentage number!

1. Definition

First of all, we start by going through the definition: “Scrum is a management and control process that cuts through complexity to focus on building products that meet business needs” (scrum.org) and “Scrum is an Agile framework for completing complex projects” (scrumalliance.org)

2. How does it work?

scrum framework to use for a Sprint

Product owner creates a prioritized wish list called a product backlog.
During sprint planning, the team pulls a small chunk from the top of that wish list, a sprint backlog, and decides how to implement those pieces.
The team has a certain amount of time — a sprint (usually two to four weeks) — to complete its work, but it meets each day to assess its progress (daily Scrum).
Along the way, the ScrumMaster keeps the team focused on its goal.
At the end of the sprint, the work should be potentially shippable: ready to hand to a customer, put on a store shelf, or show to a stakeholder.
The sprint ends with a sprint review and retrospective.
As the next sprint begins, the team chooses another chunk of the product backlog and begins working again.

3. Some know-hows

Scrum Team

The Scrum Team consists of a Product Owner, the Development Team, and a Scrum Master. Scrum Teams are self-organizing and cross-functional.

Cross-functional teams have all competencies needed to accomplish the work without depending on others not part of the team. The team model in Scrum is designed to optimize flexibility, creativity, and productivity.

Product Backlog

Product Backlog The Product Backlog is an ordered list of everything that might be needed in the product and is the single source of requirements for any changes to be made to the product. The Product Owner is responsible for the Product Backlog, including its content, availability, and ordering.

A Product Backlog is never complete. The earliest development of it only lays out the initially known and best-understood requirements. The Product Backlog is dynamic; it constantly changes to identify what the product needs to be appropriate, competitive, and useful. As long as a product exists, its Product Backlog also exists.

The Product Backlog lists all features, functions, requirements, enhancements, and fixes that constitute the changes to be made to the product in future releases. Product Backlog items have the attributes of a description, order, estimate and value.

The Development Team is responsible for all estimates. The Product Owner may influence the Development Team by helping it understand and select trade-offs, but the people who will perform the work make the final estimate.

The Scrum Product Backlog shall not contain the detailed requirement information. Ideally the final requirements are defined together with the customer during the sprint. Breakdown and distribution of these requirements is the responsibility of the Scrum Team.

Sprint Backlog

The Sprint Backlog is the set of Product Backlog items selected for the Sprint, plus a plan for delivering the product Increment and realizing the Sprint Goal

The Product Owner

The Product Owner is responsible for maximizing the value of the product and the work of the Development Team. How this is done may vary widely across organizations, Scrum Teams, and individuals.

The Product Owner is the sole person responsible for managing the Product Backlog. Product Backlog management includes:

  • Clearly expressing Product Backlog items;
  • Ordering the items in the Product Backlog to best achieve goals and missions;
  • Optimizing the value of the work the Development Team performs;
  • Ensuring that the Product Backlog is visible, transparent, and clear to all, and shows what the Scrum Team will work on next; and,
  • Ensuring the Development Team understands items in the Product Backlog to the level needed.

The Product Owner may do the above work, or have the Development Team do it. However, the Product Owner remains accountable.

The Product Owner is one person, not a committee. The Product Owner may represent the desires of a committee in the Product Backlog, but those wanting to change a Product Backlog item’s priority must address the Product Owner.

For the Product Owner to succeed, the entire organization must respect his or her decisions. The Product Owner’s decisions are visible in the content and ordering of the Product Backlog. No one is allowed to tell the Development Team to work from a different set of requirements, and the Development Team isn’t allowed to act on what anyone else says.

3. Common problems

How big is a Scrum Team?

Optimal Development Team size is small enough to remain nimble and large enough to complete significant work within a Sprint.

Having more than nine members requires too much coordination.Large Development Teams generate too much complexity for an empirical process to manage

What are the differences between user stories and tasks?

A user story is typically functionality that will be visible to end users. Developing it will usually  involve a programmer or tester, perhaps a user interface designer or analyst, perhaps a database designer, or others.

A task, on the other hand, is typically something like code this, design that, create test data for such-and-such, automate that, and so on. These tend to be things done by one person.

So, perhaps the better distinction is that stories contain multiple types of work (e.g., programming, testing, database design, user interface design, analysis, etc.) while tasks are restricted to a single type of work.

How detailed should tasks within a user story be?

The Scrum Guide doesn’t suggest that tasks are required, and it doesn’t recommend task size or a specific estimation process. It does suggest that refinement of product backlog with details and estimates is an ongoing process and “usually consumes no more than 10 percent of the capacity of the development team.” So, while the Guide doesn’t suggest how much detail should go into user stories or tasks, it does advise time-boxing the time spent in planning and refinement.

Getting the right level of detail for the user stories and associated tasks during a sprint planning meeting can be a challenge. The team needs to have enough detail to implement the story, but they also need to be efficient in their sprint planning meeting. Creating tasks that take about a day or less is the most common practice.

What should we do in Sprint Planning?

In Sprint Meeting, the Product Owner presents each item and explains how he/she sees it working from a functional perspective. The whole team discusses the item in detail. The whole team asks questions about the feature in order to establish what it should do and how it should work. You can use whatever form of writing requirements you want to. But the important principle in Scrum, and in any agile development methodology, is that you write requirements feature by feature, just before they are developed.

What really happens in Sprint Planning?

The first thing you must do (in your first Sprint Planning meeting) is decide on your Sprint duration.

The second part of the Sprint Planning Workshop is focused on breaking the requirements into tasks and estimating the hours required to complete them. Make sure the meeting is attended by all team members. Include all roles. Business Analysts if you have them. Testers if you have them. ALL Developers on the Scrum team for the product. The Product Owner and any customer, user or business representatives need not attend this part (part 2) of the Sprint Planning workshop, as it’s likely to be more technical in nature and is more about the team working out how the selected backlog items will be delivered. However, they should be welcome to attend if they wish, which may help their understanding of what’s involved to deliver the features, and may help if any further clarification is required as the tasks are discussed and estimated.

What do tasks look like in Scrum?

Tasks may include the traditional steps in a development lifecycle (although limited to the feature in question, not the entire product). For instance: Design, Development, Unit Testing, System Testing, UAT (User Acceptance Testing), Documentation, etc.

Keep tasks small. Estimate all tasks in hours. Estimate each task as a team. Ideally task estimates should be no more than 1 day. If an estimate is much larger than this, the requirements should be broken down further so the tasks are smaller. Although this can be difficult, it will get easier with practice.

Always include some additional scope in your Sprint Backlog, over and above what you think can be achieved. This is important in order to have something ready if the team delivers early, as the Sprint should ideally remain a fixed length.

Clearly identify these items as Stretch Tasks. The Product Owner should never expect Stretch Tasks to be reached. No-one should ever be beaten up if Stretch Tasks are never reached. And if you do manage to complete any Stretch Tasks, this should be cause for celebration!

Reference

  • https://www.scrum.org/resources/what-is-scrum
  • https://www.scrumalliance.org/why-scrum/scrum-guide
  • https://techbeacon.com/how-detailed-should-tasks-within-user-story-be-agile-teams
  • http://www.allaboutagile.com/how-to-implement-scrum-in-10-easy-steps-step-3-sprint-planning-requirements/
  • http://www.allaboutagile.com/how-to-implement-scrum-in-10-easy-steps-step-4-sprint-planning-tasks/
  • https://www.mountaingoatsoftware.com/blog/the-difference-between-a-story-and-a-task

Kỹ năng viết User Story với nguyên lý INVEST

Mở  đầu

User Story là một khái niệm căn bản khi làm việc theo phương pháp Agile. Mỗi User Story là một yêu cầu bất kì đối với sản phẩm nhằm hướng tới mục tiêu mang lại giá trị tốt hơn cho khách hàng. Thông thường các user story được tách riêng lẻ trong bảng Backlog (bảng lưu trữ các yêu cầu sản phẩm) nên còn được gọi là Product Backlog Item (PBI)

user story

Trong bài viết này chúng ta sẽ đi sâu vào cách viết 1 PBI tốt bằng phương pháp INVEST

Independent

Trước hết, mỗi PBI cần là một yêu cầu độc lập, không phụ thuộc vào bất kì PBI khác trong tính năng.

Các PBI có thể liên kết với nhau theo hướng tham khảo hoặc dùng như là một điều kiện tiên quyết, tính năng bổ trợ nhưng bản thân yêu cầu của từng PBI là hoàn toàn riêng biệt.

Đây là yêu cầu đầu tiên vì nếu không có sự tách biệt thì sẽ dẫn tới sự chồng chéo, dư thừa. Tổn hao công sức của Product Owner.

First thing you need is to ensure the PBI is independent, not replicate others.

Negotiable

Một PBI cần có tính linh hoạt. Cho tới trước khi nó được giao vào một tiến trình phát triển sản phẩm thì một PBI có thể được chỉnh sửa, viết lại, bổ sung bất kì lúc nào.

Tại sao lại cần linh hoạt? Vì thực tế nhu cầu của thị trường, của khách hàng luôn luôn thay đổi. Phương pháp Agile nhấn mạnh tính quan trọng của việc luôn thích ứng với thực tế, không ngại thay đổi. Đó là lý do của nguyên tắc này.

Real business always changes, don’t freeze your requirements.

Valuable

Hãy chắc rằng một PBI mang lại giá trị nào đó cho sản phẩm, người dùng. Không cần phải giải thích thì ai cũng biết rằng khi chúng ta làm một điều gì đó thì tất nhiên phải hướng tới việc tạo ra giá trị. Trong phát triển sản phẩm cũng vậy, bạn cần nhìn lại xem điều mình dự định làm có mang lại giá trị gì trong ngắn hạn, trung hạn, dài hạn không?

Do things valuable and you will absoluately be happy with your work.

Estimable

Có thể định lượng được. Hãy chắc rằng bạn hiểu cơ bản cần bao lâu để làm xong một yêu cầu. Luôn có 3 yếu tố xác định thành công của một dự án – sản phẩm đó là THỜI GIAN – CHẤT LƯỢNG – GIÁ CẢ. Bạn cần cân nhắc kĩ yếu tố đầu tiên – Thời Gian trong mối tương gian với các yếu tố khác để quyết định thứ tự ưu tiên của các PBIs.

Time passes and cannot be back.

Small

Đủ nhỏ và đơn giản. Ngay từ đầu 1 PBI chỉ là một yêu cầu đơn lẻ nhằm giúp Product Owner có thể dễ dàng định lượng độ ưu tiên của các tính năng. Chính vì vậy hãy đảm bảo 1 PBI không quá lớn để có thể hiểu và nắm bắt nhanh.

Simplicity is simply perfect.

Testable

Có thể kiểm tra, đánh giá được thành quả. Một yêu cầu có tốt đến mấy trong ý tưởng nhưng không có cách đánh giá thì không có gì đảm bảo kết quả làm ra đúng với mong đợi. Vì vậy hãy đảm bảo mô tả của bạn có đầy đủ thông tin để đánh giá chính xác mong muốn của yêu cầu.

Measuring is always a hard thing to do.

 

công việc tìm hiểu nghiệp vụ

Happy investigating!

  •  https://en.wikipedia.org/wiki/INVEST_(mnemonic)
  •  https://www.agilealliance.org/glossary/invest
  •  http://agileforall.com/new-to-agile-invest-in-good-user-stories

Kỹ năng uỷ quyền và giao việc theo mô hình SMART

Làm việc với con người chưa bao giờ là một công việc dễ dàng. Thế nhưng “cái khó ló cái khôn”, luôn luôn có những bài học vô giá mà người đi trước để lại cho các thế hệ sau bí quyết để giải quyết các vấn đề khó khăn. Đối với vấn đề giao việc, mô hình SMART là một trong những mô hình nổi tiếng và hiệu quả nhất mà một nhà quản lý nào cũng cần phải nắm vững.

leadership1

SMART là một từ tiếng anh, mỗi chữ cái là một nguyên lý được viết tắt. Sau đây chúng ta sẽ lần lượt đi từng nguyên lý một.

S – Specific

Bất kì điều gì giao ra cần phải rõ ràng. Sẽ chẳng có ý nghĩa gì nếu người khác làm một điều không đúng với ý muốn của bạn. Tất cả mọi thứ sẽ trở thành công cốc. Lãng phí tài nguyên, lãng phí cơ hội, lỡ hẹn với khách hàng, đối tác, …

Bạn cần rất rõ ràng, từng chi tiết, đặc biệt là các vấn đề dễ nhầm lẫn. Hãy đặt ra các câu hỏi quan trọng như nguyên tắc 5W (what, where, why, who và which)

attention to detail

M – Measurable

Phải định lượng được. Bất kì yêu cầu gì đưa ra cần phải có khả năng cân đong, đo đếm để đánh giá tình trạng của nó. Nếu không có cách đánh giá thì công việc không bao giờ có thể hoàn thành. Việc có khả năng đánh giá tình trạng công việc còn giúp tránh tình trạng

Đây là lúc các câu hỏi về How cần được đưa ra để biết được kế hoạch thực hiện công việc, cách đáng giá từng công đoạn, …

measurable

A – Attainable / Agreed / Achievable

Mục tiêu đề ra là khả thi, có thể đạt được. Một lẽ dĩ nhiên là bạn không thể cứ mơ tưởng được đi trên cung trăng rồi giao cho nhân viên của mình tìm cách chế tạo một chiếc du thuyền có khả năng bay lên mặt trăng trong vài ngày.

Công việc chỉ có thể hoàn thành và hoàn thành đúng hạn nếu các kì vọng vào nó là hiện thực, được người làm công việc đó xác nhận là có thể làm được.

team-meeting

 

R – Relevant / Realistic / Resourced / Relevant

Không có điều gì là hoàn hảo nhưng sự phù hợp nhất là thứ mà chúng ta luôn tìm kiếm. Nếu chỉ cần xong việc và không quan tâm tới tương lai, bạn có thể bỏ qua nguyên tắc này. Nếu ngược lại, bạn cần lùi lại một bước để nhìn thấy viễn cảnh xa hơn cho tổ chức, công ty khi giao một công việc.

Công việc này có phục vụ một mục tiêu chung của tổ chức, có tạo ra giá trị mà bạn đang hướng tới. Người thực hiện công việc có phải là người tốt nhất để làm công việc này? Liệu họ có đủ kiến thức và kinh nghiệm cũng như việc này có giúp họ phát triển bản thân thêm?

Chúng ta cần suy ngẫm nhiều hơn bên ngoài bản thân công việc đang cần giao.

T – Time Dependent / Time-bound

Businessman following leader

Cuối cùng mà nói, bạn cần một mốc thời gian cụ thể để nghiệm thu công việc. Việc có một cột mốc giúp người thực hiện thấy được mức độ ưu tiên, tập trung vào những vấn đề quan trọng cần làm để hoàn thành đúng kế hoạch.

Hạn mức thời gian này cần có được sự tán thành và xác thực của người thực hiện như là một thành tố của công việc được giao.

 

Chúc các bạn thành công trên vai trò một người quản lý.

good-manager

 

Tham khảo

  • www.therightquestions.org/delegation-authority-smart-way
  • www.businessballs.com/delegation.htm
  • www.marketing4u.vn/2011/07/ky-nang-uy-quyen-giao-viec-nhung-nguyen.html
  • www.businessballs.com/acronyms.htm#smarter-acronym

Các từ viết tắt liên quan tới SMART: Significant, Simple, Stretching; Meaningful, Motivational, Manageable; Attainable, Achievable, Appropriate, Actionable, Ambitious, Assignable, Action-oriented; Relevant, Results-focused/oriented, Resourced, Rewarding; Time-framed/based, Timely, Timed, Timetabled, Trackable, Tangible; Evaluated, Enjoyable; Rewarded, Rewarding

 

Người bán hàng một phút – The one minute sales person

Có  một nghịch lý kì hiệu: “Khi giúp người khác đạt được điều họ mong muốn thì chính ước mơ của bạn cũng sẽ dần trở thành hiện thực”

nguoibanhangmotphutpng

Chắc hẳn ai cũng hiểu rằng “càng đi sâu vào công việc bán hàng, ta càng hiểu rất rõ rằng điều cơ bản nhất mà một người bán hàng cần phải trang bị cho bản thân đó là khả năng đối phó với sự từ chối của khách hàng.” Bởi lẽ “bản chất thực sự của công việc bán hàng là Sự giao tiếp giữa những Con người với nhau”.

Tuy nhiên, “người bán hàng phải luôn nhớ mục tiêu của mình là tăng thêm doanh thu, tức là đem lại thu nhập cho bản thân, nhưng đồng thời cũng phải đem lại giá trị thực sự cho người mua”. Từ đó, chúng ta nhận thấy nghịch lý được nêu ở đầu bài: “Tôi cảm thấy vui hơn và nhận ra mục tiêu càng đến gần với mình hơn khi tôi bắt đầu giúp người khác đạt được điều họ muốn thay vì cố đạt cho được điều mình muốn”. “Giống như phải cho củi vào đốt trước khi muốn được sưởi ấm vậy, họ biết rằng chính họ phải đáp ứng nhu cầu của khách hàng trước khi muốn thu lợi nhuận về”.

Mục đích bán hàng của tôi là giúp mọi ngừoi hài lòng về

những sản phẩm mà họ đã mua và hài lòng về bản thân họ.

Bạn cần “tự hào về bản thân khi nghĩ rằng mình đang giúp khách hàng nhận ra những giá trị gia tăng mà họ sẽ có được” :D. Bởi lẽ “khách hàng luôn nhận ra mức độ quan tâm mà ta dành cho họ”.

Hãy lắng nghe khách hàng để hiểu nhu cầu của họ và bạn sẽ bán được hàng nếu sản phẩm của bạn đáp ứng được một trong những nhu cầu chính yếu nhất của họ.

Ngoài ra, bản thân người bán hàng phải luôn tự quản lý tốt bản thân, duy trì một sự tự tin thường trực. Nói một cách ngắn gọn, “để đương đầu với những thách thức trong một thế giới không ngừng thay đổi này, chúng ta phải sẵn sàng thay đổi tất cả, mọi thứ trừ niềm tin”.

Mong rằng mọi người đều thu được nhiều giá trị về cuốn sách vô cùng bổ ích này.

cho đi là nhận lại

Chúng ta rồi sẽ ổn thôi

Với hai luồng văn khác biệt của Gào và Minh Nhật, “Chúng ta rồi sẽ ổn thôi” mang đến cho người đọc những góc nhìn rất người, rất thật và rất khác lạ của những con người mang trong mình máu nghệ sĩ. Đọc tản văn này, ta như được chiêm nghiệm lại những từng trải trong đời tác giả.

chung ta roi se on thoi

Có những thứ tham khảo thì vẫn chỉ có giá trị tham khảo, bởi … “Có những thứ hoàn toàn phụ thuộc vào cảm nhận. Bạn không ở đó, khó lòng đánh giá nó, chỉ bằng mắt nhìn.”

Ai cũng ngại khó khăn, nhưng … “Nếu bạn nề hà chuyện cùng người mình yêu thương vượt qua khó khăn trong cuộc sống, có nghĩa là bạn không hề yêu họ”

“Con người ghét chờ đợi, … Nhưng chẳng phải chúng ta vẫn luôn chờ đợi một điều gì đó sao?” Và rằng … “Sự thật là chờ đợi một điều kỳ diệu chính là thứ chúng ta vẫn thường làm trong cuộc đời này.”

“Những quyết định lớn có thể thay đổi cuộc đời người ta đôi khi chỉ đến từ những điều thật đơn giản mà thôi” nhưng dù gì hãy làm một việc là “Hãy luôn yêu người ở bên cạnh mình”.

Bởi chỉ có tâm hồn và cảm xúc là vĩnh cửu, còn “Những gì bạn sở hữu phần lớn sẽ quay lại sở hữu con người bạn, tâm hồn bạn…”

Hãy đọc để cảm nhận tản văn này bạn nhé 😉

Thiết lập và sử dụng hệ thống phiên bản – API system

Hệ  thống API là gì?

API là viết tắt của chữ Application Programming Interface, dịch thuần Việt là “Giao diện lập trình ứng dụng”. Hiểu một cách sâu sắc hơn thì đó là những chuẩn kết nối, giao tiếp nhằm lấy thông tin hay dịch vụ do một bên cung cấp cho một hoặc một số bên khác sử dụng, có thể trừu tượng hoá bằng hình sau:

API schema

Tác dụng của API?

  • Ứng dụng khả năng hiện thực cấu trúc micro-service trong phát triển phần mềm (chia nhỏ các chức năng thành các module nhỏ)
  • Cung cấp back-end side cho webapp, mobile apps
  • Sử dụng các tiện ích dịch vụ từ bên thứ 3 (3rd party service) như xác thực và lấy thông tin người dùng thông qua Facebook, Google, Stripe, etc. Đây là tác dụng phổ biến và dễ thấy nhất. Ngoài các dịch vụ về xác thực, mạng xã hội, API còn mang tới sự cung cấp dịch vụ thanh toán online, chỉnh sửa hình ảnh, gửi tin nhắn sms, chữ kí điện tử, upload/download files, etc.
  • Cung cấp dịch vụ ra bên ngoài (đứng vai trò là 3rd party service)

Mô thức hoạt động của API

Với bản chất là một giao diện, các thông tin về cách sử dụng API cần được công khai với người dùng, ít nhất là với các nhà lập trình của bên đối tác. Tất cả phương thức tiếp nhận, máy chủ và dữ liệu trả về đều do một tổ chức cụ thể nào đó cung cấp (API provider).

API provider sẽ chịu trách nhiệm vận hành máy chủ của họ và mở các cổng giao tiếp phù hợp cho người dùng sử dụng. Mọi vấn đề về dữ liệu lỗi, quá tải, sai ý nghĩa của cổng giao tiếp so với dữ liệu trả về đều do bên API provider chịu trách nhiệm.

Chính vì thế, khi sử dụng API, chúng ta gần như phải phó mặc chất lượng cho nhà cung cấp vì bản thân chúng ta không quyết định được gì cả. Chúng ta chỉ thấy và chỉ có khả năng làm những gì mà họ cho phép và cung cấp (dù cái họ cung cấp là dữ liệu sai, chậm, không rõ ràng :D)

scsb-toolkit-whatistoolkit

Tiếp theo chúng ta sẽ đi tới các kinh nghiệm quan trọng về API của bản thân người viết và từ góp nhặt thông tin.

Các lưu ý trong việc sử dụng API

  • Đôi khi những gì API provider cung cấp là không khả thi cho yêu cầu của khách hàng/quản lý dự án, người phát triển phần mềm cần dùng các thông tin và ví dụ cụ thể để chứng minh điều đó và đề xuất các giải pháp tốt nhất có thể. Đừng đâm đầu quá sâu vào vấn đề nằm ngoài phạm vi giải quyết của mình.
  • Một số nhà cung cấp lớn vẫn có hệ thống documentation vô cùng tệ hại làm cho việc hiện thực API integration của nhà phát triển là một cuộc thử sai dài, bạn cần chấp nhận vấn đề này ^_^. Tuy nhiên, nên tận dụng tối đa tiện ích hỗ trợ của họ (nếu có) bằng cách hỏi thẳng những thắc mắc.
  • Nếu nhà phát triển sản phẩm dùng một thư viện mã nguồn mở để đẩy nhanh tốc độ tích hợp API, việc có lỗi hay các warning khó chịu là bình thường vì không ai có trách nhiệm đảm bảo điều đó không xảy ra với bạn. Vì thế, “có qua có lại”, nếu bạn có thể giải quyết một vấn đề nào đó, hãy đóng góp mã nguồn của bạn để khắc phục cho cả những người khác (chẳng phải bạn cũng đang dùng lòng tốt của người khác hay sao?!).

Các lưu ý trong việc phát triển API

  • API versioning là việc chia phiên bản cho hệ thống API mà bạn cung cấp. Tại sao phải chia phiên bản API? Vì bạn muốn giữ nguyên mọi thứ liên quan đến hệ thống API cũ và cung cấp một hệ thống API hoàn toàn mới, không ảnh hưởng tới những tích hợp API cũ. Ví dụ: google/v1/user/lehoang1417 sẽ trả về handsome nhưng google/v2/user/lehoang1417 sẽ trả về awesome 😀
  • Tuỳ sự độc lập trong thiết kế hệ thống mà nguy cơ thay đổi mới sẽ ảnh hưởng tới các phiên bản cũ nhiều hay ít. Nhưng trong trường hợp nào thì bạn cũng cần ý thức và đề phòng vấn đề này.
  • Đối với mobile apps, khi đã release thì ta không thể thay đổi API version mà nó gọi tới nếu như chúng ta chỉ quyết định phiên bản API trả về theo cái mà nó request lên. Vì thế cần thật cẩn thận trong các lần release.
  • Tuy nhiên, có một cách có thể thay đổi mobile apps’ requests API version một cách chủ động bằng cách trong request của app phải có cả app_type và app_version. Chúng ta sẽ dựa vào đó quyết định version trả về mong muốn.

Chúc các bạn sử dụng và nghiên cứu API thành công 🙂

have_fun